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 <ol...@adacore.com> wrote:
On Aug 14, 2020, Nathan Sidwell <nat...@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).
