IA-64 ABI meeting results

[Jim Dehnert]

The following is a brief summary of what happened in the IA-64 base ABI
meeting a couple weeks ago.  It is primarily for the benefit of the C++
ABI group (and therefore includes only the C++-relevant issues), but
I hope the attendees can also correct my memory as necessary.
If you do, or if you want to discuss things further, it would be nice
to separate issues and change the email subject :-).

>Issue 72:  COMDAT group sections
>	http://reality.sgi.com/dehnert_engr/abi/prop-72-comdat.html
>	http://reality.sgi.com/dehnert_engr/abi/prop-72-comdat.pdf
>
>	This is critical to C++ features like vtables, inline
>	functions, etc.

The group was in general agreement with this.  Joel (SCO) will write up
the necessary gABI changes.


>Issue 74:  Section indices
>	http://reality.sgi.com/dehnert_engr/abi/prop-74-sindex.html
>	http://reality.sgi.com/dehnert_engr/abi/prop-74-sindex.pdf
>
>	This is a longer term concern, which will become more important
>	with heavy COMDAT usage.

There was also general agreement that this was necessary, but more
discussion on details.  Issues that came up were:

- Using fields in the reserved section header 0 for the overflow
  section count and string section index risks breaking code that is
  depending on the currently specified zero values, e.g. by using them
  as a sentry to terminate a loop.  Discussion of alternatives, i.e.
  extending the ELF header or avoiding the string table overflow by
  requiring that its index be "small" were ultimately rejected as no
  better, leaving us with the originally proposed overflow fields.

- What is done with indices that are small enough to fit in the symbol
  table fields when the overflow table is required and present?  Must
  they be correct in both places?  Or may the overflow table contain
  zero and require reference to the original?

  The resolution (as I recall) is to require correct values in the
  overflow table, so all references to it will be valid, even though
  the symbol table value must always be checked first anyway (to detect
  the reserved special values).  An implementation could presumably
  either put real values in the symbol table, or always put the
  overflow value there and require reference to the overflow table,
  though that would not be optimal.

- How are the reserved section indices (0xff00-0xffff) treated outside
  the original symbol table fields?  Should they remain reserved,
  leaving a hole in the section number space?  Should we have no
  reserved full indices, since they're only (currently) used in symbol
  table indices?  Should we reserve different indices at the high end
  of the 32-bit index space?

  The resolution (as I recall faintly) is to reserve new values at the
  high end of the range, and avoid the hole.  Am I correct?

I will update my proposal to reflect these clarifications.
Then Joel will need to draft gABI changes.


>Issue 73/83:  Stack unwind interface
>	http://reality.sgi.com/dehnert_engr/cxx/abi-eh.html
>	http://reality.sgi.com/dehnert_engr/cxx/abi-eh.pdf
>
>	This is mostly consistent with, but more completely specified
>	than, the current SW Conventions description.

No objection was raised.  Cary has looked at it and sees no conflict
with the current specification.  This should go into the psABI
document, but no drafter has been identified.


>Issue 89??:  IPLT relocations
>	I sent a proposal a while back to extend these to .o files.
>	Cygnus has expressed concern about conflict with the lazy
>	loading semantics, which would be resolved by a second
>	relocation which is identical but doesn't allow lazy binding.
>	I don't care which approach is taken, in fact being able to
>	force early binding might be useful in any case, but C++ will
>	need to be able to relocate functions descriptors in vtables.

There was little or no discussion of this at the meeting.  The most
recent comment is Cary's:

> I don't think there's a conflict -- I'm hoping that the lack of further 
> discussion on this issue indicates general agreement. Lazy binding is 
> tied to the DT_JMPREL entry, not to the semantics of the IPLT relocation. 
> At HP, it's been our intent for quite a while to use the IPLT relocations 
> for this purpose, but we haven't planned any lazy binding support for 
> vtables (the bookkeeping is considerably harder than for PLT entries), so 
> these relocations will not be part of our DT_JMPREL set.

We should try to resolve this at the next meeting.  Does this meet your
concerns, Richard?


>Issue 82:  Priority Initialization Feedback

There is a base ABI group reluctance to specify something that is
C++-specific.  I will attempt to clarify for the group the minimum base
ABI requirement to support this feature under our proposals.  (I do
interpret the reluctance as favoring the original proposal over
required linker sorting.  However, I suspect that given all vendors'
support for C++, the underlying reluctance is unrealistic and can be
overcome.)


>Issue 90??:  Types
>	I sent a note a couple of days ago.  We must decide whether
>	__int64 and __float80 are distinct types, or typedefs of long
>	long and long double.  As Martin pointed out, we should also
>	specify bindings of the sized types defined by C2000.

Cary observed that these "types" in the conventions document were
intended purely as an expository tool, and volunteered to clarify that.

--

For the C++ group, I don't think any of the results require revisiting
decisions yet.

Jim

-		Jim Dehnert  x3-4272