[ia64-abi] Issue reminder

[dfp at sco.com]

-----BEGIN PGP SIGNED MESSAGE-----

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

I'm not happy with the lack of a direct connection between
the symbol table and its parallel section.  It seems like
we could designate one of the entries in the symbol table
index 0 to be another sh_link equivalent.

Also, even though we don't have to produce ELF files that
use this extension, pretty much all ELF tools will need to
change to handle this.  This is in contrast to the COMDAT
proposal, for example.  I'm not sure that there's anything
we can do to address this issue without this impact, but
it is at the very least annoying.

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

> Yes.  This is mostly a C++ issue, but it also matters for C.
> 
> First of all, consider the following C code:
>     void f(__int64);
>     void f(long n) {}
> This is valid if __int64 is a typedef for long, otherwise it's
> an error.

Strangely, there doesn't seem to be an entry for "long"
in the IA64 conventions.  Take a look at Table 4-1.  Since
it's LP64, we all know that [signed] long and unsigned long
should be in the 8, 8 integer entries.

I also believe that the intent of __int64 is that it was
just a nomenclature convenience for 64 bit integers, just
like __int128 is for 128 bit integers.  Since the document
is really describing binary representations, there is no
requirement that there be anything like these names accepted
as keywords (or predefined macros) in any compiler.

As such, there's no issue about use of __int64 in source
code.  If implementations choose to provide such a name, I'm
confident that they'll "do it right".

The same argument applies to __float80 and __float128.

> Second, C99 specifies a whole lot of typedefs and macros for integer
> types.  inttypes.h is a C header, and it's important for everyone to
> agree on its contents.

The IA-64 LP64 conventions and ABI make the contents of
this header pretty much fall out without much thought.
If an implementation provides a 128 bit integer, then
it will have a different intmax_t (and so on) than those
implementations that have at most a 64 bit integer.  I
don't see any reason why we have to specify anything for
<inttypes.h> or <stdint.h>.

Dave Prosser dfp at sco.com (908)790-2358 Rm A332, SCO, Murray Hill, NJ
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBONJT8L3l4qe5Xxg5AQHJWgP/TZF5QB/urv8R2YQoLGmLyVEKWe3i3HcS
k+cInDsqt36ovvkLozUr/Hvww11IZSW+E5/jb9NIrkVN8T4+Br4kuWO8uZH+NPey
9gHqbmI/OAPreQmwFkxgQJF8OY9qblJN+xFGvBHXZGicH0JB/IpHPp77MqdDtV45
7sqzSwzOyxU=
=RnS4
-----END PGP SIGNATURE-----