[PATCH] introduce attribute exalias

Iain Sandoe iain@sandoe.co.uk
Sat Aug 15 09:22:30 GMT 2020


Hi Alexandre,

I built the patch on x86_64-linux and darwin*** (fwiw).

* It’s firmly agreed that there are times when referring to C++ mangled names
   is less than ideal.

* IIUC, the objective is to have a short-hand way of annotating an export  
from
  C++ so that it’s (a) more human-readable and (b) independent of any platform
  variation in mangling of types - in the Ada import pragma?

I see Nathan commented that there are no language-lawyering implications,
which is good.

However, there do seem to be both ABI and engineering implications:

  * if the target ABI does not support symbol aliases, then this facility cannot
    be used.  Which either means that you cannot rely on this facility (and thus
    make things generically easier in the Ada implementation on GCC) or you
    will exclude the GCC targets without symbol aliases from Ada.  The latter
    would make me sad as Darwin maintainer.

  * the symbol table will grow (maybe one doesn’t care if there are not many).

  * The process shifts the onus on representation to the exporter and thus there
    can now be 3 library vendors who all thought “MY_FOO_FUNC” was the
    best representation for an export - these will now clash in the “shorthand”
    namespace, although their C++ mangling might well not.

  * it’s not universally usable without “rebuilding the world” and having access to
    source for everything you might want to import (maybe not important, depends
    on whether there are users of Ada who depend on closed source libraries).

  * what happens for templates and overloads - presumably the Ada import has
    add the relevant (albeit abbreviated) decorations?

  * One can’t have an arbitrary re-name; it has to be supported by the target
    assembler (not that this is a new constraint, but it prevents the exported
    name from being an exact representation of the human-readable C++ interface
    in general).

—— are there other possibilites to solve the underlying issue?

  C++ mangled names have some proven good properties:

  * they convey all the relevant information about the interface
  * they are standardized, and work between implementations from different
   ‘vendors’ or OSS compilers on the same platform.
  * they are not going to clash.

The compiler already has a proven implementation of C++ mangling rules.

what about annotating the import pragma in some way such that the platform
mangling is applied by the compiler?

thus, in my example below, so long as the interface is represented  
correctly by the
string after “itanium:” it will mangle correctly for the target  (even if  
that mangling would
alter between targets for representation of some types).

I suppose there’s a question of how many pragmas would be needed to annotate
sufficiently to get the mangling right?

        pragma CPP_Constructor (New_Animal);
        pragma Import (CPP, New_Animal, itanium:”Animal()");

It seems one ideally wants the Ada moral equivalent of:

extern “C++” {
   things we want to import.
}

which automagically does the right interface transforms and synthesizes the
Ada interfaces required.

Alexandre Oliva <oliva@adacore.com> wrote:

> On Aug 14, 2020, Nathan Sidwell <nathan@acm.org> wrote:
>
>>
>> Perhaps alias is not the right name at all.
>
> I kind of like the explicit present of "alias" because, well, what we
> get is an alias, to the point that, if asm aliases aren't available, it
> won't work.  And, if they are, you can use the so-assigned name as an
> alias target, so it's a good thing if they're typographically related.
>
> One could even argue that this new attribute is more deserving of the
> term alias than the existing one, and that the existing one should be
> renamed to "aliased_to" or so.  But I'm not seriously suggesting us to
> rename a long-available attribute while assigning uses thereof a
> different semantics, that would be preposterous.
>
> Since you don't seem to have liked 'aka' either, how about 'nickname',
> or 'nicknamed'?  A more convenient name to refer to an entity is exactly
> what this is about, eh?

.. assuming this facility was added ...
.. my 0.02GBP contribution the the bikeshed painting fund would be….

it’s nice when an attribute reads in the source to tell you its purpose.
so how about:

  “export_as” or “exported_as”
(depending on whether one regards this as a command to the compiler,
   or an annotation).

so :
         __attribute__ ((__export_as__ ("Ctor_For_Animal"))) // extra alias
         Animal() {Age_Count = 0;};

or:
         __attribute__ ((__exported_as__ ("Ctor_For_Animal"))) // extra alias
         Animal() {Age_Count = 0;};

thanks
Iain

*** right now Darwin fails silently (there doesn’t seem to be the usual error
  that the target doesn’t support that kind of alias).



More information about the Gcc-patches mailing list