Re: [PATCH] introduce attribute exalias
Alexandre Oliva wrote:
On Aug 15, 2020, Iain Sandoe wrote:
Alexandre Oliva 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
Re: [PATCH] introduce attribute exalias
On Aug 15, 2020, Iain Sandoe wrote:
> Alexandre Oliva 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
struct foo {
static void __attribute__((__exalias__("FOO_%_%_static_method")))
static_method () {}
};
replacing % and % 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
Re: [PATCH] introduce attribute exalias
On Aug 15, 2020, Nathan Sidwell wrote:
> 'alias' is also now a confusing term, because of the concept of
> object-aliasing.
True, but it's also an established attribute name. It seems thus
desirable to bring the conceptual framework of the alias attribute to
mind through the name of the attribute used in this new feature, but
with a twist that distinguishes it from the original attribute in a
meaningful way.
> The existing alias attribute is defined as:
>> The @code{alias} attribute causes the declaration to be emitted as an alias
>> for another symbol, which must have been previously declared with the same
>> type, and for variables, also the same size and alignment. Declaring an
>> alias
>> with a different type than the target is undefined and may be diagnosed. As
>> an example, the following declarations:
> I.e. it is creating a declaration that is aliased to some other symbol
> (which has to also be emitted by the same TU due to the usual elf-like
> object file semantics). Notice it says nothing about emitting a
> *symbol*.
It's an implied expectation that declarations of language entities get
symbols associated with them, and that attribute alias causes the symbol
name associated with one declaration to refer to the same entity denoted
by the named symbol, instead of introducing a separate entity.
> The new attribute is emitting a symbol that equates the declaration it
> is attached to (i.e. the other way round).
I.e., now we have a single declaration of a language entity, and we wish
additional symbol names to be associated with it.
> Its intent is to allow code written in another language to refer to
> this definition. I imagine you'd commonly use the foreign language's
> mangling for the string provided.
What I have in mind are mnemonic, user-chosen names, rather than
machine-mangled ones.
> If we spell it 'X', consider:
> [[gnu::X ("other")]] int i;
> Most commonly, the assembly emitted would contain:
> .globl other
> .equiv other, i
> so, perhaps we should spell it 'equiv'? That's using an existing term.
Uhh, my turn to find the term meaningless. Not just because on my
machines, aliases use .set rather than .equiv. It's missing about as
much context as 'aka' and 'nickname' in the relationship to alias.
The problem we face is that alias is a symmetric relationship, in that
if X aliases Y, then Y aliases X, but attribute alias is not symmetric:
its attribute must be placed in an undefined declaration, naming the
already-defined entity.
It would have made just as much sense to make it work backwards, namely,
attaching the attribute to the defined entity, naming any other
undefined declarations that ought to refer to the same entity. That's
pretty much the attribute I propose.
Thus clearly, though "alias" is symmetric, our use thereof isn't. Our
implementation uses the phrase "alias target" to refer to the
already-defined entity that a declaration holding an alias attribute
should alias; the declaration holding the alias attribute is referred to
as an alias.
Since attribute alias is already taken, it would thus make sense to look
for opposites of alias target to denote the new attribute. Alias source
and alias origin are probably the most natural opposites of alias
target, but they don't suggest to me what we're looking for. Alias lead
might work. Alias bead might, too.
OTOH, since the alias attribute is associated with the alias
declaration, and it names an alias target; the opposite of that, with an
attribute in the alias target declaration, would best have the attribute
named alias_target (that's an attribute of the declaration, after all),
and then the named symbol would be the alias. This would be
surprisingly consistent with the current use of attribute alias:
int attribute((alias_target("Y"))) X; // X is the alias target for Y
int attribute((alias("Y"))) Z; // Z is an alias for Y
Now, if we were to use "equiv", it would make sense to think of the
current alias attribute as "equiv_to" / "alias_target".
Another possibility that occurs to me is to reuse the existing attribute
alias, but naming the equivalent symbol as a second parameter to
attribute alias, suggesting a relation alias(X,Y), building on the
existing alias(X) in which the Y is implied, and introducing a variant
in which it is the X that is implied. Alas, an explicit placeholder is
needed in this case.
Hmm, maybe such a two-argument variant of alias could be made more
readable by requiring the *second* argument to be number 2:
int attribute((alias("Y", 2))) X;
reading as imperative "alias Y to X", whereas existing uses:
int attribute((alias("Y"))) Z;
read as imperative "alias Y Z", nonsense, but taken as "alias Z to Y",
perhaps by analogy with how "give Y Z" is taken as "give Z to Y".
/me jokingly suggests inhalias and exhalias ;-)
This is enough bikeshedding for me ;-)
--
Alexandre Oliva, happy hacker
https://FSFLA.org/blogs/lxo/
Free Software Activist
GNU
Re: [PATCH] introduce attribute exalias
On 8/14/20 10:43 PM, Alexandre Oliva wrote:
On Aug 14, 2020, Nathan Sidwell wrote:
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?
I'm sorry, I think those are awful names. They convey no intent. C++ already
has at least 2 'nickname' mechanisms:
using bob = ::foo::bar;
auto = ::elsewhere::object;
'alias' is also now a confusing term, because of the concept of object-aliasing.
The existing alias attribute is defined as:
> The @code{alias} attribute causes the declaration to be emitted as an alias
> for another symbol, which must have been previously declared with the same
> type, and for variables, also the same size and alignment. Declaring an alias
> with a different type than the target is undefined and may be diagnosed. As
> an example, the following declarations:
I.e. it is creating a declaration that is aliased to some other symbol (which
has to also be emitted by the same TU due to the usual elf-like object file
semantics). Notice it says nothing about emitting a *symbol*.
The new attribute is emitting a symbol that equates the declaration it is
attached to (i.e. the other way round).
Its intent is to allow code written in another language to refer to this
definition. I imagine you'd commonly use the foreign language's mangling for
the string provided.
If we spell it 'X', consider:
[[gnu::X ("other")]] int i;
Most commonly, the assembly emitted would contain:
.globl other
.equiv other, i
so, perhaps we should spell it 'equiv'? That's using an existing term.
nathan
--
Nathan Sidwell
Re: [PATCH] introduce attribute exalias
HI Alexandre I don’t want to derail the discussion - but FIO mostly…. Alexandre Oliva wrote: On Aug 15, 2020, Iain Sandoe 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. 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
Re: [PATCH] introduce attribute exalias
On Aug 15, 2020, Iain Sandoe wrote: > what about annotating the import pragma in some way such that the platform > mangling is applied by the compiler? Oh, one more thing about this. Requiring all names to be given in canonical form might alleviate some of the problems I raised, since it would eliminate typedefs and using declarations and directives from consideration. We'd still have other unsurmountable problems to deal with, but more importantly, you wouldn't be able to use u64 any more, you'd have to resolve it to the type that u64 is mapped to, at which point you'd be bringing back the very variation across targets that this feature was designed to overcome. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer
Re: [PATCH] introduce attribute exalias
On Aug 15, 2020, Iain Sandoe 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.
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.
>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.
> * 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:
extern "C" typeof(foo::func)
__attribute__((__alias__("")))
MY_FOO_FUNC;
Now, this concern appears to be focused on binary-only libraries. Since
we haven't seen vendors rush to make their library internals available
under shorter aliases, polluting the symbolic namespace, I see little
reason for concern about this possibility.
When it comes to binary-only libraries, the ABI is often set in stone,
and it's up to users to figure out the symbol names in the ABI and use
them. If they vary across target platforms, that's inconvenient, but
nothing new.
I expect this feature to be used and useful within multi-language
projects, particularly when using, as part of their interfaces,
shorthand typedefs whose encoding varies depending on the platform.
E.g., consider a function or a template instantiation that takes a
int64_t parameter. Depending on whether int64_t maps to long or long
long, you get different encodings, thus references using the symbol name
have to be adjusted depending on what type stdint.h maps int64_t to.
> * it’s not universally usable without “rebuilding the world” and having
> access to
>source for everything you might want to import
You mean it does not bring improvements to situations in which you can't
introduce nicknames for third-party symbols. You then figure out and
import the mangled names and move on.
> * 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.
> * 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).
*nod*. It couldn't be a target for alias attributes otherwise, and I
found that a desirable property to make the new feature useful even for
standalone C++.
> —— 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.
Consider you have to figure out the correct mangling for this:
foo::bar::f
Is foo a namespace, a canonical class name, or a typedef? (maybe even a
using declaration, or even something brought into the global namespace
by a using directive)
If it's a typedef, what's the canonical name? (it could be a template
instantiation)
bar is clearly a template type, so you "just" need enough symbolic
information to be able to mangle std::iostream&, std::string, u64,
g::h.
For u64, you just have to look at stdint.h to see which of the
C++-defined types is maps to.
g::h is a mystery. It could be a type, a function, a member function, a
variable, a
Re: [PATCH] introduce attribute exalias
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 wrote:
On Aug 14, 2020, Nathan Sidwell 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).
Re: [PATCH] introduce attribute exalias
On Aug 14, 2020, Nathan Sidwell wrote: > 'exalias' sounds either like a used-to-be alias *nod* > or it sounds like exa-lias, making me wonder what a 'lia' is, and why > I want 10^18 of them heh >>> I'm sure we can bikeshed the name 'exalias' doesn't seem very mnemonic >>> to me. 'symbol_alias' or something? >> I don't like symbol_alias; that this feature names a symbol is not a >> distinguishing feature from the preexisting alias attribute. > right, I realize this is different to the existing alias. The point was that the existing alias already takes a symbol name. > It's always struck me that the existing semantics are not c++ > friendly. Indeed, avoiding the need for using mangled symbol names to refer to language entities is the very issue I've set out to solve. It helps with aliases in C++ as much as it helps with imports in Ada. > 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? -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer
Re: [PATCH] introduce attribute exalias
On 8/14/20 3:24 PM, Alexandre Oliva wrote: On Aug 14, 2020, Nathan Sidwell wrote: This seems a useful feature. I don;t think it needs language lawyering -- it's an extension, right? Well, yeah, but I think it's usually good for even extensions to be sound language-wise. By 'same-linkage', do you mean same linkage as the *symbol* of the thing it is aliasing, or same linkage as the language entity it is aliasing? I suspect you mean the former. Yeah, ultimately the symbol declared as exalias gets the same object-level linkage and visibility properties as those of the primary symbol emitted for the language entity. Conceptually, the entity introduced by the attribute is not even visible or accessible in the standard language; it can only be referenced by alias attributes and by Ada import declarations, but conceptually, in as much as you conceive of it as a separate entity, I suppose it makes some sense to say it gets the same linkage as the entity it refers to. thanks for the discussion. I should have said, 'exalias' sounds either like a used-to-be alias, it is an ex alias, it has ceased to be, gone to join the choir invisible. or it sounds like exa-lias, making me wonder what a 'lia' is, and why I want 10^18 of them I'm sure we can bikeshed the name 'exalias' doesn't seem very mnemonic to me. 'symbol_alias' or something? I don't like symbol_alias; that this feature names a symbol is not a distinguishing feature from the preexisting alias attribute. right, I realize this is different to the existing alias. It's always struck me that the existing semantics are not c++ friendly. Perhaps alias is not the right name at all. You're emitting an alternative symbol, for use in interfacing to a foreign language/system. Perhaps 'xenoname'? 'ex' can be read as both extra, exported, external, and all of these sort of make sense, at least for entities that have linkage. Even for exclusively internal uses, say to introduce a mnemonic symbol for another alias-attributed declaration to refer to, the "ex" prefix, that means the opposite of "in", fitting in well with the functionality of "ex"posing the symbol through a name that other alias declarations can take *in*, *im*port. Another possible spelling for this proposed attribute that might be more mnemonic is "aka"; unfortunately, that's pretty much a synonym to alias, so it might be mistaken as such, rather than as a complementary feature, akin to the other end of a power extension cable: whereas alias does the job of a plug, *ex*alias provides a socket/*out*let. nathan -- Nathan Sidwell
Re: [PATCH] introduce attribute exalias
On Aug 14, 2020, Nathan Sidwell wrote: > This seems a useful feature. I don;t think it needs language > lawyering -- it's an extension, right? Well, yeah, but I think it's usually good for even extensions to be sound language-wise. > By 'same-linkage', do you mean same linkage as the *symbol* of the > thing it is aliasing, or same linkage as the language entity it is > aliasing? > I suspect you mean the former. Yeah, ultimately the symbol declared as exalias gets the same object-level linkage and visibility properties as those of the primary symbol emitted for the language entity. Conceptually, the entity introduced by the attribute is not even visible or accessible in the standard language; it can only be referenced by alias attributes and by Ada import declarations, but conceptually, in as much as you conceive of it as a separate entity, I suppose it makes some sense to say it gets the same linkage as the entity it refers to. > I'm sure we can bikeshed the name 'exalias' doesn't seem very mnemonic > to me. 'symbol_alias' or something? I don't like symbol_alias; that this feature names a symbol is not a distinguishing feature from the preexisting alias attribute. 'ex' can be read as both extra, exported, external, and all of these sort of make sense, at least for entities that have linkage. Even for exclusively internal uses, say to introduce a mnemonic symbol for another alias-attributed declaration to refer to, the "ex" prefix, that means the opposite of "in", fitting in well with the functionality of "ex"posing the symbol through a name that other alias declarations can take *in*, *im*port. Another possible spelling for this proposed attribute that might be more mnemonic is "aka"; unfortunately, that's pretty much a synonym to alias, so it might be mistaken as such, rather than as a complementary feature, akin to the other end of a power extension cable: whereas alias does the job of a plug, *ex*alias provides a socket/*out*let. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer
Re: [PATCH] introduce attribute exalias
On 8/14/20 11:39 AM, Alexandre Oliva wrote:
Ping?
In case there isn't immediate approval for the patch proper (I suppose
different parts will require review by different subsystem maintainers),
I'd appreciate at least community and language lawyers buy-in (or
turn-down) for the new feature hereby proposed for C-family languages,
namely, attribute exalias("symbol_name") as a means to have symbol_name
output as a same-linkage alias for functions, variables, and for C++
class types' RTTI symbols.
This seems a useful feature. I don;t think it needs language lawyering
-- it's an extension, right? By 'same-linkage', do you mean same
linkage as the *symbol* of the thing it is aliasing, or same linkage as
the language entity it is aliasing? I suspect you mean the former.
I'm sure we can bikeshed the name 'exalias' doesn't seem very mnemonic
to me. 'symbol_alias' or something?
nathan
Thanks in advance,
On Aug 7, 2020, Alexandre Oliva wrote:
Since last week's patchlet, I've delayed the creation of the exalias
decls, improved the merging of attributes, minimizing
interface/visibility updates, found a better way to assign exaliases to
nested explicit instantiations, even after enabling aliases to
already-defined types, so now I'm reasonably happy with the patch.
This patch introduces an attribute to add extra aliases to a symbol
when its definition is output. The main goal is to ease interfacing
C++ with Ada, as C++ mangled names have to be named, and in some cases
(e.g. when using stdint.h typedefs in function arguments) the symbol
names may vary across platforms.
The attribute is usable in C and C++, presumably in all C-family
languages. It can be attached to global variables and functions. In
C++, it can also be attached to namespace-scoped variables and
functions, static data members, member functions, explicit
instantiations and specializations of template functions, members and
classes. When applied to constructors or destructor, additional
exaliases with _Base and _Del suffixes are defined for variants other
than complete-object ones.
Applying the attribute to class types is only valid in C++, and the
effect is to attach the alias to the RTTI object associated with the
class type.
While working on this, I noticed C++ didn't merge attributes of extern
local declarations with those of the namespace-scoped declaration.
I've added code to merge the attributes if there is a namespace-scoped
declaration, but if there isn't one, there won't be any merging, and
the effects are noticeable, as in the added attr-weak-1.C. I'm also
slightly concerned that an earlier local decl would go out of sync if
a subsequent local decl, say within the same or even in another
function, introduces additional attributes in the global decl.
Regstrapped on x86_64-linux-gnu. Ok to install?
(The newly-introduced attr-weak-1.c passes in C, but is marked as XFAIL
for C++, so it gets an XPASS in C; I could move it to some C++-only
subtree, or drop it altogether and file a PR instead)
for gcc/ChangeLog
* attribs.c: Include cgraph.h.
(decl_attributes): Allow late introduction of exalias in
types.
(create_exalias_decl, create_exalias_decls): New.
* attribs.h: Declare them.
(FOR_EACH_EXALIAS): New macro.
* cgraph.c (cgraph_node::create): Create exalias decls.
* varpool.c (varpool_node::get_create): Create exalias decls.
* cgraph.h (symtab_node::remap_exalias_target): New.
* symtab.c (symtab_node::remap_exalias_target): Define.
* cgraphunit.c (cgraph_node::analyze): Create alias_target
node if needed.
(analyze_functions): Fixup visibility of implicit alias only
after its node is analyzed.
* doc/extend.texi (exalias): Document for variables, functions
and types.
for gcc/ada/ChangeLog
* doc/gnat_rm/interfacing_to_other_languages.rst: Mention
attribute exalias to give RTTI symbols mnemonic names.
* doc/gnat_ugn/the_gnat_compilation_model.rst: Mention
attribute exalias. Fix incorrect ref to C1 ctor variant.
for gcc/c-family/ChangeLog
* c-ada-spec.c (pp_asm_name): Use first exalias if available.
* c-attribs.c (handle_exalias_attribute): New.
(c_common_attribute_table): Add exalias.
(handle_copy_attribute): Do not copy exalias.
* c-decl.c (duplicate_decls): Remap exalias target.
for gcc/cp/ChangeLog
* class.c (copy_fndecl_with_name): Move/adjust exalias to
cdtor variants.
(build_cdtor_clones): Drop exalias from primary variant.
* cp-tree.h (update_exalias_interface, update_tinfo_exalias):
Declare.
* decl.c (duplicate_decls): Remap exalias target.
(grokfndecl): Tentatively create exalias decls after adding
attributes in e.g. a template member function explicit
instantiation.
* decl2.c
Re: [PATCH] introduce attribute exalias
Ping?
In case there isn't immediate approval for the patch proper (I suppose
different parts will require review by different subsystem maintainers),
I'd appreciate at least community and language lawyers buy-in (or
turn-down) for the new feature hereby proposed for C-family languages,
namely, attribute exalias("symbol_name") as a means to have symbol_name
output as a same-linkage alias for functions, variables, and for C++
class types' RTTI symbols.
Thanks in advance,
On Aug 7, 2020, Alexandre Oliva wrote:
> Since last week's patchlet, I've delayed the creation of the exalias
> decls, improved the merging of attributes, minimizing
> interface/visibility updates, found a better way to assign exaliases to
> nested explicit instantiations, even after enabling aliases to
> already-defined types, so now I'm reasonably happy with the patch.
> This patch introduces an attribute to add extra aliases to a symbol
> when its definition is output. The main goal is to ease interfacing
> C++ with Ada, as C++ mangled names have to be named, and in some cases
> (e.g. when using stdint.h typedefs in function arguments) the symbol
> names may vary across platforms.
> The attribute is usable in C and C++, presumably in all C-family
> languages. It can be attached to global variables and functions. In
> C++, it can also be attached to namespace-scoped variables and
> functions, static data members, member functions, explicit
> instantiations and specializations of template functions, members and
> classes. When applied to constructors or destructor, additional
> exaliases with _Base and _Del suffixes are defined for variants other
> than complete-object ones.
> Applying the attribute to class types is only valid in C++, and the
> effect is to attach the alias to the RTTI object associated with the
> class type.
> While working on this, I noticed C++ didn't merge attributes of extern
> local declarations with those of the namespace-scoped declaration.
> I've added code to merge the attributes if there is a namespace-scoped
> declaration, but if there isn't one, there won't be any merging, and
> the effects are noticeable, as in the added attr-weak-1.C. I'm also
> slightly concerned that an earlier local decl would go out of sync if
> a subsequent local decl, say within the same or even in another
> function, introduces additional attributes in the global decl.
> Regstrapped on x86_64-linux-gnu. Ok to install?
> (The newly-introduced attr-weak-1.c passes in C, but is marked as XFAIL
> for C++, so it gets an XPASS in C; I could move it to some C++-only
> subtree, or drop it altogether and file a PR instead)
> for gcc/ChangeLog
> * attribs.c: Include cgraph.h.
> (decl_attributes): Allow late introduction of exalias in
> types.
> (create_exalias_decl, create_exalias_decls): New.
> * attribs.h: Declare them.
> (FOR_EACH_EXALIAS): New macro.
> * cgraph.c (cgraph_node::create): Create exalias decls.
> * varpool.c (varpool_node::get_create): Create exalias decls.
> * cgraph.h (symtab_node::remap_exalias_target): New.
> * symtab.c (symtab_node::remap_exalias_target): Define.
> * cgraphunit.c (cgraph_node::analyze): Create alias_target
> node if needed.
> (analyze_functions): Fixup visibility of implicit alias only
> after its node is analyzed.
> * doc/extend.texi (exalias): Document for variables, functions
> and types.
> for gcc/ada/ChangeLog
> * doc/gnat_rm/interfacing_to_other_languages.rst: Mention
> attribute exalias to give RTTI symbols mnemonic names.
> * doc/gnat_ugn/the_gnat_compilation_model.rst: Mention
> attribute exalias. Fix incorrect ref to C1 ctor variant.
> for gcc/c-family/ChangeLog
> * c-ada-spec.c (pp_asm_name): Use first exalias if available.
> * c-attribs.c (handle_exalias_attribute): New.
> (c_common_attribute_table): Add exalias.
> (handle_copy_attribute): Do not copy exalias.
> * c-decl.c (duplicate_decls): Remap exalias target.
> for gcc/cp/ChangeLog
> * class.c (copy_fndecl_with_name): Move/adjust exalias to
> cdtor variants.
> (build_cdtor_clones): Drop exalias from primary variant.
> * cp-tree.h (update_exalias_interface, update_tinfo_exalias):
> Declare.
> * decl.c (duplicate_decls): Remap exalias target.
> (grokfndecl): Tentatively create exalias decls after adding
> attributes in e.g. a template member function explicit
> instantiation.
> * decl2.c (cplus_decl_attributes): Update tinfo exalias.
> (copy_interface, update_exalias_interface): New.
> (determine_visibility): Update exalias interface.
> (tentative_decl_linkage, import_export_decl): Likewise.
> * name-lookup.c: Include target.h and cgraph.h.
> (set_local_extern_decl_linkage): Merge attributes with a
> namespace-scoped decl if one is found. Remap exalias
>
[PATCH] introduce attribute exalias
Since last week's patchlet, I've delayed the creation of the exalias decls, improved the merging of attributes, minimizing interface/visibility updates, found a better way to assign exaliases to nested explicit instantiations, even after enabling aliases to already-defined types, so now I'm reasonably happy with the patch. This patch introduces an attribute to add extra aliases to a symbol when its definition is output. The main goal is to ease interfacing C++ with Ada, as C++ mangled names have to be named, and in some cases (e.g. when using stdint.h typedefs in function arguments) the symbol names may vary across platforms. The attribute is usable in C and C++, presumably in all C-family languages. It can be attached to global variables and functions. In C++, it can also be attached to namespace-scoped variables and functions, static data members, member functions, explicit instantiations and specializations of template functions, members and classes. When applied to constructors or destructor, additional exaliases with _Base and _Del suffixes are defined for variants other than complete-object ones. Applying the attribute to class types is only valid in C++, and the effect is to attach the alias to the RTTI object associated with the class type. While working on this, I noticed C++ didn't merge attributes of extern local declarations with those of the namespace-scoped declaration. I've added code to merge the attributes if there is a namespace-scoped declaration, but if there isn't one, there won't be any merging, and the effects are noticeable, as in the added attr-weak-1.C. I'm also slightly concerned that an earlier local decl would go out of sync if a subsequent local decl, say within the same or even in another function, introduces additional attributes in the global decl. Regstrapped on x86_64-linux-gnu. Ok to install? (The newly-introduced attr-weak-1.c passes in C, but is marked as XFAIL for C++, so it gets an XPASS in C; I could move it to some C++-only subtree, or drop it altogether and file a PR instead) for gcc/ChangeLog * attribs.c: Include cgraph.h. (decl_attributes): Allow late introduction of exalias in types. (create_exalias_decl, create_exalias_decls): New. * attribs.h: Declare them. (FOR_EACH_EXALIAS): New macro. * cgraph.c (cgraph_node::create): Create exalias decls. * varpool.c (varpool_node::get_create): Create exalias decls. * cgraph.h (symtab_node::remap_exalias_target): New. * symtab.c (symtab_node::remap_exalias_target): Define. * cgraphunit.c (cgraph_node::analyze): Create alias_target node if needed. (analyze_functions): Fixup visibility of implicit alias only after its node is analyzed. * doc/extend.texi (exalias): Document for variables, functions and types. for gcc/ada/ChangeLog * doc/gnat_rm/interfacing_to_other_languages.rst: Mention attribute exalias to give RTTI symbols mnemonic names. * doc/gnat_ugn/the_gnat_compilation_model.rst: Mention attribute exalias. Fix incorrect ref to C1 ctor variant. for gcc/c-family/ChangeLog * c-ada-spec.c (pp_asm_name): Use first exalias if available. * c-attribs.c (handle_exalias_attribute): New. (c_common_attribute_table): Add exalias. (handle_copy_attribute): Do not copy exalias. * c-decl.c (duplicate_decls): Remap exalias target. for gcc/cp/ChangeLog * class.c (copy_fndecl_with_name): Move/adjust exalias to cdtor variants. (build_cdtor_clones): Drop exalias from primary variant. * cp-tree.h (update_exalias_interface, update_tinfo_exalias): Declare. * decl.c (duplicate_decls): Remap exalias target. (grokfndecl): Tentatively create exalias decls after adding attributes in e.g. a template member function explicit instantiation. * decl2.c (cplus_decl_attributes): Update tinfo exalias. (copy_interface, update_exalias_interface): New. (determine_visibility): Update exalias interface. (tentative_decl_linkage, import_export_decl): Likewise. * name-lookup.c: Include target.h and cgraph.h. (set_local_extern_decl_linkage): Merge attributes with a namespace-scoped decl if one is found. Remap exalias targets, and drop exaliases from the local decl. * optimize.c (maybe_clone_body): Only copy attributes if they haven't been copied yet. Update exalias interface. * rtti.c: Include attribs.h and cgraph.h. (get_tinfo_decl): Copy exalias attributes from type to tinfo decl. Create exalias decls. (update_tinfo_exalias): New. for gcc/testsuite/ChangeLog * c-c++-common/attr-weak-1.c: New, xfailed. * c-c++-common/torture/attr-exalias-1.c: New. * c-c++-common/torture/attr-exalias-2.c: New. *
