[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