+ linaro-toolchain
Hello Ulrich,
I want to revisit this old thread. Sorry for the sloppy follow-up. But,
this time around I have more data.
On Tue, Mar 15, 2011 at 9:00 PM, Ulrich Weigand
<Ulrich.Weigand(a)de.ibm.com> wrote:
> Aneesh V <aneesh(a)ti.com> wrote:
>
>> I was trying to build u-boot in Thumb2 for OMAP4. Everything was fine
>> until I added some patches recently. One of these patches introduced an
>> API (let's say foo()) that has a weakly linked alias(let's say
>> __foo()) and a strongly linked implementation(the real foo()) in an
>> assembly file.
>>
>> Although I give -mthumb and -mthumb-interwork for all the files,
>> apparently GCC generates ARM code for assembly files. In the final
>> image foobar() calls foo() using a BL. Since foobar() is in Thumb and
>> foo() in ARM, it ends up crashing. Looks like foobar() assumed foo()
>> to be Thumb because __foo() is Thumb.
>
> I'm unable to reproduce this. Do you have a complete test case?
>
> I've tried with the following small example:
>
> foo1.c:
>
> extern void foo (void) __attribute__ ((weak, alias ("__foo")));
>
> void __foo (void)
> {
> }
>
> int main (void)
> {
> foo ();
> }
>
> foo2.S:
> .text
> .align 2
> .global foo
> .type foo, %function
> foo:
> push {r7}
> add r7, sp, #0
> mov sp, r7
> pop {r7}
> bx lr
> .size foo, .-foo
>
> When building just "gcc foo1.c", I get:
>
> 0000835c <__foo>:
> 835c: b480 push {r7}
> 835e: af00 add r7, sp, #0
> 8360: 46bd mov sp, r7
> 8362: bc80 pop {r7}
> 8364: 4770 bx lr
> 8366: bf00 nop
>
> 00008368 <main>:
> 8368: b580 push {r7, lr}
> 836a: af00 add r7, sp, #0
> 836c: f7ff fff6 bl 835c <__foo>
> 8370: 4618 mov r0, r3
> 8372: bd80 pop {r7, pc}
>
> When building both files "gcc foo1.c foo2.S", I get instead:
>
> 00008368 <main>:
> 8368: b580 push {r7, lr}
> 836a: af00 add r7, sp, #0
> 836c: f000 e802 blx 8374 <foo>
> 8370: 4618 mov r0, r3
> 8372: bd80 pop {r7, pc}
>
> 00008374 <foo>:
> 8374: e92d0080 push {r7}
> 8378: e28d7000 add r7, sp, #0
> 837c: e1a0d007 mov sp, r7
> 8380: e8bd0080 pop {r7}
> 8384: e12fff1e bx lr
>
>
> So it seems to me the linker is handling this correctly ...
>
> (This is on Ubuntu Natty using system gcc and binutils.)
I could reproduce the problem on older tool-chain(Sourcery G++ Lite
2010q1-202) [1] with a modified version of your sample code:
a.c:
====
extern void foo (void) __attribute__ ((weak, alias ("__foo")));
void __foo (void)
{
}
extern void call_foo(void);
int main (void)
{
call_foo ();
}
b.S:
====
.text
.align 2
.global foo
foo:
push {r7}
add r7, sp, #0
mov sp, r7
pop {r7}
bx lr
.size foo, .-foo
c.S
.text
.align 2
.global call_foo
call_foo:
bl foo
bx lr
.global __aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr0:
bx lr
Now, I build them using the following commands, which is similar to
what U-Boot does:
arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c a.c
arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c b.S
arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c c.S
arm-none-linux-gnueabi-ld -r a.o -o alib.o
arm-none-linux-gnueabi-ld -r b.o -o blib.o
arm-none-linux-gnueabi-ld -r c.o -o clib.o
arm-none-linux-gnueabi-ld --start-group clib.o alib.o blib.o
--end-group -o a.out
armobjdump -S --reloc a.out
You will get something like:
00008094 <call_foo>:
8094: fa000006 blx 80b4 <foo>
8098: e12fff1e bx lr
Please note that that the 'blx' is not correct. Now, do the following change:
diff --git a/b.S b/b.S
index e0f2de9..96dba1f 100644
--- a/b.S
+++ b/b.S
@@ -1,5 +1,6 @@
.text
.align 2
+.type foo, %function
.global foo
foo:
push {r7}
And build it again the same way and you will see:
00008094 <call_foo>:
8094: eb000006 bl 80b4 <foo>
8098: e12fff1e bx lr
I can't reproduce this on Linaro GCC 2012.01, so looks like the problem
is solved in recent tool-chains. However, sadly I could reproduce a
different but similar problem with Linaro GCC 2012.01. This time the
call is from C(Thumb) to assembly(ARM) and no weakly linked symbols are
involved.
a.c:
====
int main (void)
{
foo ();
}
b.S:
====
.text
.align 2
.global foo
foo:
push {r7}
add r7, sp, #0
mov sp, r7
pop {r7}
bx lr
.size foo, .-foo
.global __aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr0:
bx lr
arm-linux-gnueabi-gcc -mthumb -mthumb-interwork -c a.c
arm-linux-gnueabi-gcc -mthumb -mthumb-interwork -c b.S
arm-linux-gnueabi-ld -r a.o -o alib.o
arm-linux-gnueabi-ld -r b.o -o blib.o
arm-linux-gnueabi-ld --start-group alib.o blib.o --end-group -o a.out
arm-linux-gnueabi-objdump -S --reloc a.out
gives:
8076: af00 add r7, sp, #0
8078: f000 f802 bl 8080 <foo>
807c: 4618 mov r0, r3
It should have been "blx 8080 <foo>", isn't it? Again, %function
solves it.
I agree that not marking the assembly functions ' %function' is a problem
in the code, so it's not a critical bug. But I would've been happier if
the linker refused to link it rather than branching with the wrong
instruction. Isn't that a problem?
Problem No:2
*************
Linaro GCC 2012.01 is giving a new problem w.r.to Thumb build
that is not existing in Sourcery G++ Lite 2010q1-202. However, I
couldn't reproduce this problem with a small program like above. So,
let me give you reference to the original u-boot code that shows the
problem and steps to reproduce it.
tree: git://github.com/aneeshv/u-boot.git
branch: thumb
The above branch has mainline u-boot with 4 additional patches from me
for enabling Thumb build. You can build it like this:
make CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm distclean
make CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm omap4_sdp4430
This builds two images u-boot and u-boot-spl. SPL is a tiny u-boot that
runs from internal RAM and loads the u-boot to SDRAM. Now, please have
a look at the map file of u-boot-spl which is at: spl/u-boot-spl.map
I see the following in my map file:
/spl/u-boot-spl.map:
=================
.rodata.wkup_padconf_array_essential_4460
0x40309583 0x4 board/ti/sdp4430/libsdp4430.o
0x40309583 wkup_padconf_array_essential_4460
.rodata.wkup_padconf_array_essential
0x40309587 0xc board/ti/sdp4430/libsdp4430.o
0x40309587 wkup_padconf_array_essential
.rodata.core_padconf_array_essential
0x40309593 0x60 board/ti/sdp4430/libsdp4430.o
0x40309593 core_padconf_array_essential
Please note that the .rodata symbols have odd addresses. These arrays
actually need to be aligned at least to half-word boundary. In fact, in
the image I verified that they are put at even addresses. So, the
symbols have been kept as real address +1. I understand that this is
the convention for Thumb functions. I guess the tool-chain did it for
data too?? And I am getting unaligned access aborts on accessing them.
I notice that this doesn't happen with all .rodata. symbols in the
image. I couldn't see any difference between working and non-working
files nor any difference in the command used to build them!
Well, this doesn't happen if I don't use "-fdata-sections" in gcc
options. So, apply the following patch and you will see that those
symbols have even addresses now.
diff --git a/config.mk b/config.mk
index ddaa477..723286a 100644
--- a/config.mk
+++ b/config.mk
@@ -190,7 +190,7 @@ CPPFLAGS := $(DBGFLAGS) $(OPTFLAGS) $(RELFLAGS) \
# Enable garbage collection of un-used sections for SPL
ifeq ($(CONFIG_SPL_BUILD),y)
-CPPFLAGS += -ffunction-sections -fdata-sections
+CPPFLAGS += -ffunction-sections
LDFLAGS_FINAL += --gc-sections
endif
/spl/u-boot-spl.map:
=================
.rodata 0x40309204 0x38c board/ti/sdp4430/libsdp4430.o
0x40309204 core_padconf_array_essential
0x40309264 wkup_padconf_array_essential
0x40309270 wkup_padconf_array_essential_4460
0x40309274 core_padconf_array_non_essential
0x40309540 wkup_padconf_array_non_essential
0x40309588 wkup_padconf_array_non_essential_4430
Will you be able to look into these?
Thanks,
Aneesh
[1] Sourcery G++ Lite 2010q1-202
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1
GNU ld (Sourcery G++ Lite 2010q1-202) - binutils 2.19.51.20090709
[2] Linaro 4.6-2012.01
arm-linux-gnueabi-gcc (crosstool-NG linaro-1.13.1-2012.01-20120125 -
Linaro GCC 2012.01) 4.6.3 20120105 (prerelease)
GNU ld (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 2.22
Hi!
* Development benchmarks:
Focused on the implementation of development benchmarks in the cbuild
system. Discussed with Michael about how the comments should look.
I am now testing my solution in the launchpad staging area. You can see a
link to an example of a benchmark result comment below. (Should not be a
double comment of course, and the actual result files are only stored on my
machine for now.)
https://code.staging.launchpad.net/~ramana/gcc-linaro/partial_partial_pre_t…
The real benchmark names are not mentioned, since that might be sensitive.
* Bug reports
I got an action on Monday's meeting to investigate if
https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/926855
is the same as PR52294.
Investigated with help from Ramana and updated the ticket.
Regards
Åsa
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-??-?? || ||
(new blueprints & reestimate for this one pending Michael H's writeup/etc)
Historical Milestones:
||a15-usermode-support || 2011-11-10 || 2011-11-10 || 2011-10-27 ||
||upstream-omap3-cleanup || 2011-11-10 || 2011-12-15 || 2011-12-12 ||
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || 2012-01-17 ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?|| 2012-02-01 ||
== cp15-rework ==
* figuring out how various suggestions/conversations on this from
Connect ought to fit together
== other ==
* LP:928580 recent u-boot not booting on QEMU beagle: tracked
this down to a u-boot bug and passed to John Rigby
* investigated a linux-user segfault deadlock which turns out to
be because the guest program is using setrlimit to restrict
memory usage and one of qemu's internal memory allocations then
fails. Not clear how best to fix but was able to nack the suggested
patch...
* most of the patches for passing a device tree to the kernel from
qemu (via -dtb option) are now upstream; rebased the final patch
which should now go in soon I think
* LP885239 qemu-linaro broke booting of zaurus models: fixed a bug
where a trustzone support patch had broken some cp15 registers for
xscale cpus
* minor patch: fixed formatting of list of supported machines help text
* fix an embarrassing segfault bug in a patch of mine committed last week
* it turns out that we can detect at compile time whether glibc's
makecontext() is an always-fails stub : sent configure patch to do this
* travel mostly set up for connect Q2.12
* lots of meetings/training: toolchain call; standup; 1-2-1;
project management training; comms meeting
I've added a Cortex-A8 benchmark machine to my home office. The
machine is called 'nova1' and is part of the cbuild a8-ref queue.
Feel free to give it jobs:
http://ex.seabright.co.nz/helpers/scheduler/spawn
-- Michael
Hi,
GDB on Android exploration:
* Familiarizing myself with the Android SDK and NDK, and the Android
runtime environment.
* Set up a Linaro Android Versatile Express image running on Linaro
qemu. Updated the wiki page [1] with instructions on how to prepare
its initrd to make it palatable to qemu.
* Trying to figure out if there's a way to get the SDK and NDK to talk
to that image.
* Studied AOSP's patches to gdbserver, and also Mozilla's patches to
AOSP's GDB and gdbserver.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
[1] https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress
I've changed the bounce host used to gain access to the boards at my
home office. The ports and configuration are the same but you will
get a scary error due to the SSH host key changing.
Let me know if there are any problems,
-- Michael
* Linaro GCC
Discovered that part of my conditional execution problems were caused by
some over-zealous peephole optimizations adding CC register clobbers to
arithmetic operations in order to take advantage of the 16-bit encoding.
This is a problem because they can't be converted to conditional
execution so freely because overwriting the CC register prevents any
further conditional execution (and forces a 32-bit encoding
unnecessarily). I wrote a patch to help ifcvt unpick all this and DTRT,
and posted it upstream. It turns out that Benrd (I think) already
reimplemented the peephole optimization in the reorg pass, so all that
is really needed is to delete the now obsolete peepholes. Richard E has
approved the revised patch. Unfortunately I've now discovered that that
exposed a bug in the machine description, so that'll have to be fixed also.
Tried to update the gcc-linaro/4.7 branch, but found the build broken.
In fact, Matthias had already reported it to Bugzilla. I did a binary
search, identified the problem commit, posted the info to bugzilla, and
pushed a merge request for the last working commit for testing. This
tested ok, so I've merged it to the Linaro 4.7 trunk.
Brought the Linaro GCC patch tracker up to date to aid identification of
patches we will need to forward port to 4.7. The remaining 'red' patches
are either not committed upstream, or I wasn't sure.
Attempted to benchmark the 64-bit shift improvements, but the target
board (ursa1) has developed an I/O error.
* Other
Joe Seymour and I went to HP Bristol to attend one of their science
lectures. Professor Jim Al-Khalili gave a talk about the recent
"faster-than-light" neutrinos experiments, and explained why it can't
possibly be true.
http://www.jimal-khalili.com/blog/faster-than-the-speed-of-light.html
Summary:
* crosstool-ng patches for linaro 2012.02 binary toolchain release
Details:
1. Revise the gdb lsb build patches based on gdb-7.4.
2. Clean up old patches and only keep the latest version, since we
only keep the latest version in config for linaro.
3. Window installer patch.
* Scripts to use installjammer to create the win32 install package.
* Apply linaro logo to the install package.
* Sync up the install directory and Start-menu layout with
embedded toolchain.
* Test the package on win7.
Plans:
* Finalize 2012.02 binary toolchain release.
Best regards!
-Zhenqiang
Hi,
libunwind
* discussions about local unwinding on Android
* problem: dl_iterate_phdr isn't available
* idea: parse proc/<pid>/maps but to find the ELF file for a given IP
and get to the ARM specific unwind info from there
* assisted an Android game developer who is using clang to compile
the native parts of the app, the ndk to link it and wondered why
the debuggerd doesn't catch any crashes
OpenEmbedded
* mainly worked on the linaro meta layer
* got the external binary toolchain recipe working
* added the Linaro 3.1 Kernel to the layer
* updated documentation:
https://wiki.linaro.org/KenWerner/Sandbox/OpenEmbedded-Core
Regards,
Ken
