All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: Poky Project <poky@yoctoproject.org>
Subject: Bad ARM code with GCC 4.7.1
Date: Thu, 10 May 2012 08:28:00 -0600	[thread overview]
Message-ID: <4FABD070.9090100@mlbassoc.com> (raw)

After updating to the latest master, I'm running into trouble
using GCC 4.7.1 with my ARM kernel(s).

The problem code is in mm/percpu.c - this function [header]

static void pcpu_dump_alloc_info(const char *lvl,
				 const struct pcpu_alloc_info *ai)
{
	int group_width = 1, cpu_width = 1, width;
	char empty_str[] = "--------";
	int alloc = 0, alloc_end = 0;
	int group, v;
	int upa, apl;	/* units per alloc, allocs per line */

generates this code:

    0xc03669d0 <pcpu_dump_alloc_info>:   ldr     r3, [pc, #532]  ; 0xc0366bec <pcpu_dump_alloc_info+540>
    0xc03669d4 <pcpu_dump_alloc_info+4>: push    {r4, r5, r6, r7, r8, r9, r10, r11, lr}
    0xc03669d8 <pcpu_dump_alloc_info+8>: sub     sp, sp, #52     ; 0x34
    0xc03669dc <pcpu_dump_alloc_info+12>:        ldr     r2, [r3]
    0xc03669e0 <pcpu_dump_alloc_info+16>:        mov     r4, r1
    0xc03669e4 <pcpu_dump_alloc_info+20>:        mov     r10, r0

which in turn generates an alignment exception at pcpu_dump_alloc_info+12

The same code generates this using GCC 4.6.3

    0xc02bf6b0 <pcpu_dump_alloc_info>:   push    {r4, r5, r6, r7, r8, r9, r10, r11, lr}
    0xc02bf6b4 <pcpu_dump_alloc_info+4>: sub     sp, sp, #52     ; 0x34
    0xc02bf6b8 <pcpu_dump_alloc_info+8>: mov     r4, r1
    0xc02bf6bc <pcpu_dump_alloc_info+12>:        mov     r2, #9
    0xc02bf6c0 <pcpu_dump_alloc_info+16>:        str     r0, [sp, #20]
    0xc02bf6c4 <pcpu_dump_alloc_info+20>:        add     r0, sp, #39     ; 0x27
    0xc02bf6c8 <pcpu_dump_alloc_info+24>:        ldr     r1, [pc, #444]  ; 0xc02bf88c <pcpu_dump_alloc_info+476>
    0xc02bf6cc <pcpu_dump_alloc_info+28>:        mov     r9, #1
    0xc02bf6d0 <pcpu_dump_alloc_info+32>:        bl      0xc017f2a0 <memcpy>

Which looks much better to me - the runtime assignment
	char empty_str[] = "--------";
should cause the 9 byte string "--------" to be copied to the
stack variable.

I even tried to rewrite the code to match GCC 4.6.3 as
         char empty_str[10];
         memcpy(empty_str, "--------", 9);
but GCC 4.7.1 managed to generate the same bad code :-(

If I disable CONFIG_OPTIMIZE_FOR_SPEED, i.e. use -O2 instead of -Os,
this function is compiled properly.  Sadly, there are other gremlins
in there as Linux-3.0 still crashes when built with GCC 4.7.1

Are these known problems?  Are there work arounds?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


             reply	other threads:[~2012-05-10 14:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-10 14:28 Gary Thomas [this message]
2012-05-10 15:46 ` Bad ARM code with GCC 4.7.1 Khem Raj
2012-05-10 16:17   ` Gary Thomas
2012-05-10 16:30     ` Khem Raj
2012-05-10 16:49       ` Mark Hatle
2012-05-10 17:00         ` Khem Raj
2012-05-10 17:08       ` Gary Thomas
2012-05-10 20:06         ` Martin Jansa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FABD070.9090100@mlbassoc.com \
    --to=gary@mlbassoc.com \
    --cc=poky@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.