Re: [PATCH] introduce attribute exalias

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

Alexandre Oliva <oliva@adacore.com> wrote:

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

Yes - or, in fact, linker-visible ones for Darwin because of the issue below.

>  I meant it was often used for local labels.

… including for Darwin targets;
one has to take care with details sometimes, since a local label defines
something that is part of the atom delineated by the next preceding global
(or linker-visible) symbol (or section start if there are none).

When the local label does not really belong to that atom, it can cause
problems (e.g. apparently branching to code that is weak global) so we insert
a non-global (but linker-visible) symbol to allow a new atom to start.

>> 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 where one wanted to import the declaration of a function without
having to include every header needed to declare the types it uses.

Since a header unit should be self-contained and is a compiled artefact.

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

perhaps not, it was only “thinking aloud”
(since we are agreed it would be nice to have a solution that the compiler
could manipulate/synthesize, rather than requiring source-level changes).

FAOD, the comments above are just continuation of discussion - not any
additional objection to the proposal.

thanks
Iain