HI Alexandre
I don’t want to derail the discussion - but FIO mostly….
Alexandre Oliva <ol...@adacore.com> wrote:
On Aug 15, 2020, Iain Sandoe <i...@sandoe.co.uk> wrote:
* if the target ABI does not support symbol aliases, then this facility
cannot
be used.
True. I'm surprised there are modern platforms that don’t.
different platforms have different designs - it’s not an “old c.f
new” thing - see below.
What is it that stands in the way? Lack of support for .set in the
assembler?
If that's the case, couldn't it possibly be worked around by
setting multiple global labels at the same spot? I'm pretty sure
setting multiple labels at the same address is used and relied on quite
often.
That’s what’s currently disallowed (the assemblers all support .set).
Long ago (before my time with GCC) Darwin’s toolchains did support
aliases.
The withdrawal was not an accident, but a design choice - where a linker
model based on “atoms” was chosen (which requires [as things stand]
public symbols to have distinct addresses). I can point you at a description
of the linker optimisation if you’re interested.
IMO, the atom model can be modified to allow aliases (it might be even
that the linker constraint has been relaxed already).
However, it’s not my call - I’ve suggested to the platform toolchain team
it’s
a good idea, but it doesn’t seem to block any other toolchain than GCC
so not sure what priority would be assigned.
For function aliases, I think there’s a simple work-around and it’s just a
question of time for me to make a patch etc.
for general aliases to public symbols including data, not so easy.
will exclude the GCC targets without symbol aliases from Ada.
It's not so dire. Developers for alias-deprived systems would have to
use the mangled names instead. That would be a little painful, but not
even close to making the language unavailable.
Well the predicate was that the use of the mechanism was mandatory, if
the existing scheme continues of course there’s no issue.
* 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.
Using this to disqualify the new feature would also disqualify regular
aliases, that could be used for just the same purpose of making symbols
available under chosen names:
It wasn’t a comment against the feature - but a comment about shifting the
onus for export information onto the producers (and the fact that one can’t
generally control what they choose to provide in the absence of a
specification
- which itanium mangling is).
* what happens for templates and overloads - presumably the Ada import has
add the relevant (albeit abbreviated) decorations?
They don't matter to the proposed design. The reason they come up for
you is that you have a completely different solution in mind that
requires this kind of resolution. The one I'm proposing attaches the
extra aliases directly to the target language entity, be it one of the
overloads of a member function, be it a specialization of a template
function.
Actually, I was thinking about folks who like template metaprogramming
(not personally a fan) - and how they would arrange to get automatic
export information to track that meta-progamming.
Solved if one were able to import the interface….
—— 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.
* they require so much symbolic information that in order to perform
mangling you pretty much have to #include all of the relevant C++
headers.
Consider typedefs, templates with partial or explicit specializations,
default template arguments, besides the possibility of varying
definitions across platforms.
what about annotating the import pragma in some way such that the platform
mangling is applied by the compiler?
That would indeed be desirable, but it is unfortunately not viable.
<snipped explanation>
I see.
Thinking aloud - not thought through in any detail - I wonder if the
facilities of
C++20 modules are sufficient?
*** right now Darwin fails silently (there doesn’t seem to be the usual
error
that the target doesn’t support that kind of alias).
Hmm, thanks, I will make sure there's some more verbose failure mode if
we can't find a way for something akin to an alias to be usable there.
I imagine it will be easy to fix a diagnostic output.
Iain
