[PATCH roland/ehdr_start] Use __ehdr_start, when available, for rtld to get its own headers.

[Mike Frysinger]

On Wed 06 Aug 2014 00:35:25 Mike Frysinger wrote:
> On Mon 24 Mar 2014 15:30:33 Roland McGrath wrote:
> > > this breaks on ia64 w/binutils-2.23.2.  using gcc-4.7.3 in case it
> > > matters.
> > 
> > Sorry about that.  But I think you're going to have to do most of the
> > legwork on investigating what's going wrong here, as I do not have any
> > ia64
> > worlds to test on.
> > 
> > It seems fairly certain that this must be binutils (ld) bugs.  Since ld.so
> > is linked with -z defs, it should not have gotten out alive with an
> > undefined symbol.  What does its .dynsym from readelf -W -s look like?
> > 
> > Does adding -Wl,-z,defs to LDFLAGS in the configure check make it fail?
> > (I'm guessing not, since the link of ld.so didn't fail.)
> > 
> > Probably we can find a way to detect the bug with readelf -r.
> > Send me your binary and or readelf -WSsr output so I can fiddle.
> 
> hmm, so the symbol is actually defined in ld.so:
> $ readelf -sW elf/ld.so | grep ehdr
>     32: 0000000000000000     0 NOTYPE  GLOBAL HIDDEN     1 __ehdr_start
>    493: 0000000000000000     0 NOTYPE  GLOBAL HIDDEN     1 __ehdr_start
> 
> but i guess the fact it's marked HIDDEN is the problem ?

the source declares it as hidden though.  i was comparing it to x86_64 where 
it doesn't:
   252: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    1 __ehdr_start
then again, x86_64 doesn't add it to the exported symbol list, but ia64 does.

x86_64 also doesn't have a reloc like ia64:
00000000000505c8  0000002000000027 R_IA64_DIR64LSB        0000000000000000 
__ehdr_start + 0

so i guess linker bug for not fully resolving that reloc.  i wonder if it can 
be easily tested for (the simple code in the configure.ac didn't generate a 
reloc).  or maybe i should force this off in the ia64 configure script until 
the linker bug can be tracked down.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20140806/e5ca66f4/attachment.sig>