Re: [PATCH] introduce attribute exalias

[Alexandre Oliva <oliva@adacore.com>]

On Aug 15, 2020, Iain Sandoe <iain@sandoe.co.uk> wrote:

> Alexandre Oliva <oliva@adacore.com> wrote:

>> 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).

I understand you mean it's disallowed for global labels.  I meant it was
often used for local labels.


> 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.

Yeah, one possibility that comes to mind is to output additional text
symbols (akin to PLT entries) that just jump to the intended target.

> for general aliases to public symbols including data, not so easy.

*nod*

As far as I'm concerned, function aliases as above would be enough to
address the issue I was asked to address.  The RTTI aliases are only
used to import and catch C++ exception in Ada.  I suppose a mnemonic
would be just as welcome, but if it's not available, the mangled name
will have to do.


> 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.

There's no (current) way to import C++ templates as Ada generics; the
best you can do is to import C++ template instantiations/specializations
as Ada records, procedures and functions.  This, and the lack of a
symbolic representation of generics, has driven me to introduce
user-chosen named aliases for specializations, rather than to the
generics.

I've considered enabling symbolic mnemonic template names to be
associated with templates, say:

template <typename T, typename U>
struct foo {
  static void __attribute__((__exalias__("FOO_%<T>_%<U>_static_method")))
  static_method () {}
};

replacing %<T> and %<U> with the mangling for the template arguments,
but that would bring us back the problem of varying mangled names as
mnemonic types like u64 get resolved to the mangling of their
target-dependent language types, defeating the purpose of referencing
cross-platform symbol names from Ada.

> Thinking aloud  - not thought through in any detail - I wonder if the
> facilities of
> C++20 modules are sufficient?

I'm really not sure what issue you're thinking of solving.

The one I'm working on is that of enabling the use of a uniform string
in Ada import statements (and also in alias("targets")), even when a
symbolic type that does not mangle uniformly is in use (think int64_t
mapping to long or long long).  Having per-target source files is quite
cumbersome in Ada, and there isn't a preprocessor to rely on for
conditionals and token pasting and whatnot.

I'm afraid I don't see how C++ modules could any offer in this regard.


>> 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.

*nod*

-- 
Alexandre Oliva, happy hacker
https://FSFLA.org/blogs/lxo/
Free Software Activist
GNU Toolchain Engineer