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
------------------------------------------------------------
next 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.