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

[Roland McGrath <roland at hack dot frob dot com>]

> 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 ?

No, it's supposed to be STV_HIDDEN.  It should not be in .dynsym at all,
though (I think the first grep hit is in .dynsym and the second in
.symtab).  Also there should be no dynamic relocs referring to the symbol;
it's presumably because there is one that it appears in .dynsym.  The
runtime resolution process is reloc-driven, not symbol-driven, so the fact
that you saw any LD_DEBUG spew mentioning the name is an indication there
was a reloc.

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

The visibility has changed over iterations of the linker code.  I think
current versions deliver STV_HIDDEN for all machines, but I'm not
completely sure.

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

It would be best if you can figure out how to change the configure check so
that it fails with the buggy ia64 linker.  It might be good enough just to
make the test do readelf -r on conftest.so and complain if any relocs
mention __ehdr_start--or perhaps if there are any relocs at all (I would
expect the linker to turn it into a symbolless reloc and not export the
symbol, but that would still be a bug to have any reloc at all).  But if,
as you say, the trivial example in the configure check doesn't produce a
reloc with the buggy ia64 linker, then you'll have to modify the code to
more thoroughly mirror the real ld.so case.  Figuring out how to do that
might well be tantamount to finding the linker bug.

So, I think you really should figure out the linker's bug and both get the
linker fixed and get our generic configure check to catch buggy linkers.
But forcing it off in ia64/configure is a quick workaround and is certainly
what you should do to have a working ia64 build in the 2.20 release if you
don't manage to work up the configure change in time.


Thanks,
Roland