[OE-core] Problem with new image-prelink
James Limbouris
james at digitalmatter.com.au
Tue Sep 13 02:58:57 UTC 2011
> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf Of
> Mark Hatle
> Sent: Monday, 12 September 2011 10:50 PM
> To: openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] Problem with new image-prelink
>
> Once the Linux Foundation servers come back on-line, I'll file a bug in the
> bugzilla.yoctoproject.org bug tracker.
>
> Hopefully this is something fairly simple, and fixing the target prelink-rtld
> will also resolve the failed prelinking for the QT binary.
>
> I hope to get to investigating this tomorrow. If you have time, you should be
> able to capture a core, or use gdb on the target and figure out where the bad
> alignment trap is occurring.
>
> The failure is in the "prelink-rtld" binary. Most likely when it's being run using:
>
> RTLD_WARN= RTLD_TRACE_PRELINKING=1 prelink-rtld <binary>
>
> That should fail with the same unaligned access..
>
> Once that works and no longer fails.... it should produce the same output as if
> you ran:
>
> LD_WARN= LD_TRACE_LOADED_OBJECTS=1 LD_TRACE_PRELINKING=1
> LD_BIND_NOW=1
> /lib/ld-linux.so.3 <binary>
>
> (/lib/ld-linux.so.3 is from memory so I may be wrong..) Any deviation between
> the two could point to an alternative cause to the QT failure as well.
>
> --Mark
Thanks Mark. Here is a backtrace of the alignment trap, after enabling SIGBUS when faulting:
root at 192:~# gdb prelink
<...>
Reading symbols from /usr/sbin/prelink...Reading symbols from /usr/sbin/.debug/prelink...done.
done.
(gdb) set follow-fork-mode child
(gdb) run -a
Starting program: /usr/sbin/prelink -a
[New process 1712]
process 1712 is executing new program: /usr/sbin/prelink-rtld
[ 2777.370000] Alignment trap: prelink-rtld (1712) PC=0x410f9990 Instr=0xe5922024 Address=0x00000025 FSR 0x001
Program received signal SIGBUS, Bus error.
[Switching to process 1712]
0x410f9990 in __ctype_b_loc () at ../include/ctype.h:30
30 *tablep = (const uint16_t *) _NL_CURRENT (LC_CTYPE, _NL_CTYPE_CLASS) + 128;
(gdb) bt
#0 0x410f9990 in __ctype_b_loc () at ../include/ctype.h:30
#1 __option_is_short (__opt=<optimized out>) at argp.h:579
#2 convert_options (argp=0x0, parent=0x0, parent_index=121872,
group=<optimized out>, cvt=0xbebd1b98) at argp-parse.c:335
#3 0x410f9938 in convert_options (argp=0x4114f210, parent=0x0,
parent_index=3200064088, group=<optimized out>, cvt=0xbebd1b98)
at argp-parse.c:406
#4 0x410f9c80 in parser_convert (flags=0, argp=0xbebd1a58, parser=0xbebd1ae0)
at argp-parse.c:435
#5 parser_init (input=0x0, flags=0, argv=0xbebd1e74, argc=3,
argp=<optimized out>, parser=0xbebd1ae0) at argp-parse.c:515
#6 __argp_parse (argp=<optimized out>, argc=3, argv=0xbebd1e74, flags=0,
end_index=0xbebd1cfc, input=0x0) at argp-parse.c:915
#7 0x00009784 in main (argc=1090670408, argv=0x0) at rtld.c:895
(gdb)
I've never used argp before, but I couldn't find anything wrong with rtld.c ...
Regards,
James
More information about the Openembedded-core
mailing list