This is the mail archive of the
mailing list for the GCC project.
Re: Results for 3.4-bi 20021213 (experimental) testsuite on
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: dave at hiauly1 dot hia dot nrc dot ca (John David Anglin)
- Cc: nathan at codesourcery dot com, zack at codesourcery dot com, gcc-testresults at gcc dot gnu dot org, sje at cup dot hp dot com
- Date: Tue, 17 Dec 2002 17:00:35 -0500 (EST)
- Subject: Re: Results for 3.4-bi 20021213 (experimental) testsuite on
> > (see __gthread_active_p), so I figured it was ok. The gcc docs do not
> > give a formal description of what supporting weak symbols means. I went
> > with the elf specs which (IIRC) are
> > * a weak definition is overridden by a non-weak definition
> > * an unresolved weak declaration is resolved to zero.
> If that's the case, then the hpux dynamic loader should set the address
> in the function descriptor to zero. Can you point me to the elf specs
> to which you referred?
I have played a bit more with this using the test program below. I can
link it with gnu ld and the symbol table values for __gcov_init seem
reasonable. Possibly, we need a R_PARISC_IPLT relocation for __gcov_init
but I think we are blocked by the following:
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '__gcov_init' in load module './weak'.
It doesn't seem to matter that the symbol is weak.
I looked at the SYSV elf spec and I don't think it specifies the runtime
behavior of undefined weak symbols. For function pointer comparison,
the HP compiler compares function (descriptor) pointers. The runtime
uses official function descriptors to ensure that all function pointers
that refer to the same function have the same value. In the case of
an undefined weak function, it looks like the function pointer should
Steve, I was wondering how this works on ia64 hpux. Do undefined weaks
work? If they do, do you think there is any chance that HP would consider
upgrading the linker and dynamic loader to support undefined weak on
hppa64. ia64 and hppa64 are presumably using similar code. If you
think this should already work, I would be interested in how the symbol
table values and dynamic relocations look for __gcov_init on ia64.
J. David Anglin email@example.com
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
extern void __gcov_init (void *) __attribute__ ((weak));
int main ()
return foo ();