Re: Special names tha ld needs to recognize for hppa64-hp-hpux11.X

[law@redhat.com]

 In message <200202111708.g1BH8AIA009479@hiauly1.hia.nrc.ca>, "John David 
Anglin
" writes:
 > I have a patch that leaves the dynamic-loader defined symbols undefined.
 > Something additional would be needed if we actually generated a static
 > binary and need to provide these symbols.
Right.  This could possibly be an issue for the PA64 Linux folks, but I
don't see it being an issue in HP-UX land.

 > I think so.  The ones that are provided are supposed to be linker defined
 > according to the "PA-64 Runtime Supplement".  The only questionable one
 > is __TLS_SIZE.  The HP compiler provides a default value for it equal to
 > 0xc8 (at least, it does in a trivial program) while the linker script
 > provides a value of 0.  On the other hand, I presume crt0.o initializes
 > tp (cr27).  How does it find the start of .tbss?  From the elf header?
I suspect __TLS_SIZE can probably be derived by the linker from the size of
the various .t* sections.

I haven't really studied the HP thread local storage scheme, but I suspect
it doesn't need to find the start of tbss, only tdata as the TLS sections
should be used just for initializing thread local data.

I would expect cr27 to be initialized by crt0 or the kernel.

 > That's what the HP linker does.  However, I am not sure it hurts to define
 > the dynamic loader symbols in the linker.  It's definitely simpler.
It could hurt if the symbol is defined by a module that is dl_loaded at
runtime.

 > At the moment, a more serious issue is the treatment of LTOFF_* relocations
 > in static programs (see my mail on this yesterday).  We need to fix this
 > before a decision can be made on the synamic loader defined symbols.
I missed that completely (I've been on the road most of the last week).  Can
you resend it to me privately?

jeff