This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Defining a libgnat.so, libgnarl.so ABI


> As the last of the shared GCC runtime libraries, libgnat.so and
> libgnarl.so lack symbol versioning support and a defined ABI.
> Currently, they use libgnat-4.5.so and libgnarl-4.5.so SONAMEs, what
> libtool calls release versioning.  If the libgnat/libgnarl ABI is really
> that fluent that it changes from release to release, there's obviously
> no point in defining one, but given the Ada Reference Manual, I cannot
> really believe this, but assume that this is just being cautious.

The ABI has not much to do with the language definition, although there's
certainly a mapping from one to the other, but this mapping can definitely
change.

Currently we don't make any special attempt at keeping a stable ABI in the
Ada front-end and indeed, there's no document describing a complete
"Ada ABI" to start with.

So believe it or not, but the ABI does change from release to release.

> If one would want to go forward with defining an ABI, one could start
> with the list of global symbols, as I've done in the libffi and libobjc
> cases, and remove anything that is an implementation detail.  Since I
> barely know any Ada, or Ada mangling, I cannot do this on my own, but
> would proceed with guidance from the Ada maintainers if deemed
> worthwhile.  In fact, I'd expect that it would be possible to
> mechanically generate a list of public interfaces to start from from the
> *.ads files, adding in some global functions from the runtime.

That's also only a subset of the ABI you are mentioning here.

The decisions on e.g. alignments, sizes of objects and types is not
specified at all in the Ada RM and may change, which is not acounted for
by "public interfaces" (which are really APIs rather than ABI, you seem to
be assuming that one is equal to the other).

> Suggestions, advice, discouragement :-)

The first step to having real versioning would be to have a documented Ada
ABI. The second step would be to agree on when/how this ABI may be modified.

None of these two steps exist today, so your proposal is simply not something
realistic today.

Arno


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]