[ia64-abi] Issue 82: Initializer priorities

[Jim Dehnert]

> From: Mike Walker <msw at eng.sun.com>
> 
> > On a system where the linker does no more than this, the C++
> > implementation must do the following:
> > 
> >         In bracketing files for the link (e.g. crt1.o and crtn.o),
> >         emit delimiting labels in the SHT_CXX_PRIORITY_INIT section,
> >         and entries in INITARRAY that call an initialization
> >         routine that passes the labels (all STV_HIDDEN to avoid
> >         conflicts between DSOs).  The call at the beginning would
> >         sort the SHT_CXX_PRIORITY_INIT vector by priority and invoke
> >         the negative-priority initializers, and the one at the end
> >         would invoke the positive-priority initializers.
> 
> I think it's worth hi-lighting that one of the main motivations 
> for us introducing the DT_INITARRAY & DT_FINIARRAY was so that
> we could move away from the requirement of having crt*.o
> modules when a final link is performed.  Ideally - they are no
> longer required for the ia64 development environment.
> 
> This proposal introduces a new dependency on the crt*.o modules
> which we were trying to move away from.  Is that an issue
> for others?
> 
> I know that we at Sun are a long way from being crt'less so
> it's not that big of an issue for us - but it's worth bringing up
> for discussion.

Two points to make here:

- I agree that an objective of *ARRAY was to eliminate initialization
  code patched together in crt* modules.  But this proposal doesn't
  require that -- it requires labels and INITARRAY section entries.

- More importantly, please don't take the above paragraph for more
  than was intended.  I was asked to describe the minimum linker
  requirements imposed by the the proposal, and that's what it
  presents.  I think a more reasonable implementation from someone
  serious about the feature would do the sorting in the linker and
  implicitly add the initialization calls to INITARRAY without any
  involvement from crt* files.  But one of the objectives of the design
  was not to require linker involvement, while allowing the improved
  results that can be obtained by linker sorting.

=====

> From: Cary Coutant <cary at cup.hp.com>
>
> I agree with Ulrich that "CXX" does not belong in the name.

I prefer that, too.

> But I also  believe that you don't even need a special section type.
> I don't see any 
> special treatment required of this section beyond SHT_PROGBITS.
> Your  bracketing files provide the necessary labels so that the
> initialization routine can find the section.
> 
> I understand the argument that the special section type might allow a 
> linker to do the sorting if it chose to do so, but you can do that with
> a vendor-specific section type, and the compatibility rules ensure that 
> other linkers will treat that section type properly.

Both points are correct, but the combination is deadly.  I can do
without the special section type if I choose to give up on the linker
sorting, but as I said, I think that's the preferable implementation if
one is serious about this.  And I can do linker sorting with a
vendor-specific section type, but that prevents cross-vendor
interoperability, which is the ultimate objective of this exercise.
Objects from two vendors would go in two special sections, and the
linker would sort only one of them.  Or, if you use a compiler from one
vendor and a linker from another, the linker doesn't process anything.

Personally, my objective here is not to force support of this on
anyone.  But there are already multiple vendors supporting the feature,
including Cygnus and IBM, and I'd like to see it done compatibly when
it's done, for the benefit of users.  So making this an optional
supplementary specification with a pre-assigned section type is a fine
solution from my point of view.

> This description sounds like it affects the initializer order only
> within a DSO. How does it address reordering of initializers across DSOs?

It doesn't.  We explicitly decided that attempting to intermix
initializers from different DSOs was an invitation to chaos, miserable
to implement (especially with potential delay loading), and generally
to be avoided.

=====

> From: Mark Mitchell <mark at codesourcery.com>
> ...
> So, I'm not even sure this is a great language feature, let alone
> something that we should mandate support for in the ABI.  Furthermore,
> we haven't provided a syntax for doing this, so programs using these
> features will only be portable at the object-file level anyhow -- not
> at the compiler level.

Actually, we've specified the semantics of a pragma, and have simply
postponed completing that definition until the underlying ELF issue is
resolved.  So this concern will not remain valid.

> Vendors who do not support this feature in
> their compilers may well "forget" to implement it in their linkers as
> well, rendering it a non-standard anyhow.

My understanding is that the vendors who currently have this feature
intend to carry it over to IA-64 -- they have found it to be useful (or
their customers have).  As I said above, I'd rather have a consistent
implementation from those who support it than total incompatibility.
If other vendors choose to do nothing, I don't care -- that's a quality
of implementation choice for those vendors.

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272