for 3.4-bi 20021213 (experimental) testsuite on

[John David Anglin]

> > 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.
> 
> I can pass this info on.

Here is a summary of issues that I encountered in the HP ELF implementation
when adding the capability in GCC to run initializers and finalizers.

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

Summary of areas where HP-UX 11 linker and dynamic loader are not compliant
with generic System V ABI (ELF) and impact on GCC for hppa64-hpux.

1) Undefined Weak Symbols

The HP linker and the dynamic loader attempt to resolve weak symbols.
Undefined weak symbols are supposed to resolve to a value of zero but
the HP linker and dynamic loader both generate errors for unsatisfied
weak symbols.  The ABI specifically states that the link editor should
not extract archive library members to resolve undefined weak symbols
and that unresolved weak symbols have a zero value (cf., Chapter 4 -
Object Files, Symbol Table).  The HP linker extracts archive members
to resolve undefined weak symbols.  I view fixing this as important.

2) The .init and .fini sections

The HP linker and dynamic loader incorrectly use the .init and .fini
for the init and fini arrays.  They should be using .init_array and
.fini_array.  As a result, the .init and .fini sections have the wrong
attributes.  And, as init and fini array sections, they have the wrong
type, SHT_PROGBITS (cf., Chapter 4 - Object Files, Special Sections).
This behavior is described in the PA specific ELF documentation.  I
think it would be a good idea to switch to the correct sections even
if DT_INIT and DT_FINI remain unsupported.

The order of initialization is incorrect.  The functions pointed to in
the arrays specified by DT_INIT_ARRAY and by DT_PREINIT_ARRAY should be
executed by the dynamic linker in the same order in which their addresses
appear in the array; those specified by DT_FINI_ARRAY should be executed
in reverse order.  The man page states that when using the +init option,
the initializer functions are invoked in reverse order (right to left on
command line).  This is the order that they currently are called when
using the 64-bit ELF linker.  However, they are called in the opposite
order when using the 32-bit SOM linker.

We now use DT_INIT_ARRAY and DT_FINI_ARRAY in gcc.  Changing the order
of processing the arrays could be handled but previously compiled code
would initialize/finalize in the wrong order.  We don't use the linker
command switches in GCC to add initializers/finalizers on hppa64.  However,
we want command specified initializers to run before those specified
internally by GCC.  This would be affected if the order of processing
the arrays was changed.  Thus, I would prefer that the order of processing
of the arrays not be changed.  However, the order of processing the
switches could be changed to make it compatible with the 32-bit port.
I would prefer that the 32-bit order not change as it would cause
problems for GCC.  Doing nothing except for correcting the documentation
would be fine as far as GCC goes.

3) Sorting of .ctors and .dtors

It would be nice to support priority sorting of constructors and destructors.
This is not a compliance issue.

4) GNU linkonce semantics.

Again, it would be nice to have this support.  This is not a compliance issue.