This is the mail archive of the gcc-testresults@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Results for 3.4-bi 20021213 (experimental) testsuite on


> This test of a weak function address is in the gthr-*.h headers,

We haven't enabled thread support under hpux11 because of problems
like this.  gthr-simple.h doesn't have any weak tests.  Under hpux10,
the 32-bit port used multilib configuration.

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

> That might well work, but IMHO the hpux is not supporting weak. I, of
> course, don't feel strongly about this, but would like to clarify
> what weak support means before trying to work around this problem.

I'm also pragmatic about the matter and must defer to the ELF experts
when it comes what weak support means.  The testing for unresolved
weak symbols is a very nice feature but it looks like there is quite
a bit to fix before it will work on hppa64-hpux.  I'm not sure what
the odds are of getting HP to fix their linker and possibly the
dynamic loader, but I suspect they aren't great unless the request
comes from someone with a service contract.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]