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: for 3.4-bi 20021213 (experimental) testsuite on


Thanks for trying this.

> I tried this on ia64 hpux and pa64 hpux using the HP linker on both
> systems and both give an "Unsatisfied symbol" error message.  I doubt
> that HP would consider changing this unless the ELF standard were clear
> that it should work as part of the standard.

Then, I presume that 3.4 will not build on ia64-hpux because the code
from the test appears in profile.c.  I think there was an intent in the
ELF standard to define the behavior of undefined weak symbols in that
they defined that the value of undefined weak symbols should be zero.
That's in fact what we currently have in the hppa64 implementation with
GNU ld.  However, the standard doesn't appear to define how the runtime
should handle an undefined weak symbol.

I can understand that HP might take the position that you indicated.
However, I think they should carefully consider the advantages of adopting
the behavior present in many other sysv elf systems, namely that is
possible to overload a different capability by simply linking with a
different library.  This can avoid having to use a multilib environment
for posix threads, etc.  We have been hung up in how to implement posix
thread support in hpux11 in part because of this issue.  I don't really
want to multilib both dce and posix threads.

On the otherhand, it clear HP doesn't like weak symbols in that they
don't provide compiler and assembler support for them.  It's always been
a puzzle to me that libc contains weak symbols, and yet there is no
support in the tools for weak binding or for visibility.

Nathan, I don't think the current code in profile.c is acceptable, but
I'm not an ELF standards expert.  As I said before, I don't want to disable
SUPPORTS_WEAK.

> I made some changes on IA64 so that functions that are declared but
> never used are not required.  I did this by not putting out extern's for
> them unless I see a use.  See ia64_asm_output_external (with
> TARGET_HPUX_LD set to true), ia64_hpux_add_extern_decl, and
> ia64_hpux_asm_file_end in config/ia64 for this solution.  I have a
> version for PA that I could submit.

Do you have an example where there was a problem?  I suspect that we
don't have a problem on hppa64-hpux because the GNU and HP assemblers
discard extern's (IMPORTs) that aren't used.  There was some discussion
of this on binutils not long ago when a problem related to this arose on
hppa-linux.  If we actually have a problem, I would appreciate your
patch.

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]