Re: [PATCH] introduce attribute exalias

[Iain Sandoe <iain@sandoe.co.uk>]

HI Alexandre

I don’t want to derail the discussion - but FIO mostly….

Alexandre Oliva <oliva@adacore.com> wrote:

> On Aug 15, 2020, Iain Sandoe <iain@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