[ia64-abi] Issue reminder

[Cary Coutant]

>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.

I have no issues with this proposal.


>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.

I support this proposal. One thing that's not clear, though -- are the 
section indices 0xff00 - 0xffff still reserved, or are these values 
reserved only when seen in the st_shndx field? I assume you have intended 
the latter.

I would suggest adding some wording to make it clear that the extended 
section index does not reserve the range 0xff00 - 0xffff as special 
section indices. That is, once you see SHN_XINDEX in the st_shndx field, 
what you pull out of the extension section is a real section index. (I 
haven't yet taken the time to make sure that st_shndx is the only place 
where special section indices ever get used.)

This may take some creative re-wording in the gABI document, where it 
describes the reserved section indices.


>Issue 73:  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.

This looks OK to me. I haven't found anything that directly contradicts 
the common conventions document, so if you know of anything, please point 
it out to me. Any conflict is probably the result of over-specification 
at the common conventions level, so I'd probably propose to resolve most 
conflicts by removing material from the conventions document.

This material, being Unix specific, belongs in the psABI document, but 
not in the conventions document.


>Issue ??:  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.

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.


>Issue ??:  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.

I thought you noted that this was just a C++ issue. Do we need to answer 
this at the base ABI level?


-cary