[cxx-abi-dev] Mangling of calling convention attributes

[Richard Smith]

On 5 May 2015 at 18:17, Jason Merrill <jason at redhat.com> wrote:

> On 05/05/2015 05:31 PM, John McCall wrote:
>
>> These qualifiers aren’t order-sensitive, so we need to specify the order;
>> alphabetical order is the most obvious, which I think would make this
>> mangling U11regparmLi3EU7stdcallFviiE rather than the other way around.
>>
>
>  For member pointer types, this would become part of the member type.
>> That’s also where we put ref-qualifiers and CV-qualifiers, so we need to
>> specify an order; I suggest putting these attributes after the CV/ref
>> qualifiers.
>>
>
> I was working from the passage in the ABI that says, "In cases where
> multiple order-insensitive qualifiers are present, they should be ordered
> 'K' (closest to the base type), 'V', 'r', and 'U' (farthest from the base
> type), with the 'U' qualifiers in alphabetical order by the vendor name
> (with alphabetically earlier names closer to the base type)."
>
> So I think reverse alphabetical order before the CV-qualifiers is what we
> want.
>
>  Should we mangle these as part of an entity’s type?  It’s not possible to
>> directly overload using the CC of a function itself, so it’s not strictly
>> necessary.  There’s a general issue with overloading function templates by
>> the types of non-type template parameters, but I don’t think it affects us
>> in this specific case because the argument itself resolves the ambiguity.
>>
>
> Microsoft mangles functions differently based on the calling convention,
> but I agree that it doesn't seem to be necessary.
>
> On 05/05/2015 06:40 PM, Richard Smith wrote:
>
>> It seems a little weird to nest a mangling within a source-name like that.
>>
>
> Fair enough, I was experimenting with something that wouldn't require any
> changes to the ABI or demanglers.
>
>  We had some previous discussion of arguments for vendor extensions here:
>>
>> http://sourcerytools.com/pipermail/cxx-abi-dev/2014-January/002660.html
>>
>
> Thanks for the reminder.
>
>  It looks like we ended up mangling
>>
>>   void f(bool b) __attribute__((enable_if(b, "foo"))) {}
>>
>> as
>>
>>   _Z1fUa9enable_ifIXfL0p_EEb
>>
>> ... where Ua means roughly "vendor attribute", and is followed by
>> <source-name> <template-args>. With that approach, those attributes would
>> mangle as Ua7regparmIXLi3EE and Ua7stdcallIE
>>
>
> What I see in that thread is "U", not "Ua".  And indeed, that seems
> unambiguous; no type can begin with 'I'.


The reason we chose Ua rather than U was that the ABI suggests that U4blah
should demangle as 'blah', whereas we want something that demanglers know
should become '__attribute__((blah))'. I have no particular strong feelings
here.


> So, changing
>  ::= U <source-name> <type>     # vendor extended type qualifier
> to
>  ::= U <source-name> <type> [ <template-args> ]
>
> Also, I think the 3 should use the expr-primary mangling, and it doesn't
> seem necessary to attach the "IE" to stdcall.  So,
>
> U7regparmILi3EE
> U7stdcall
>
> Make sense?
>
> Jason
>
>
> _______________________________________________
> cxx-abi-dev mailing list
> cxx-abi-dev at codesourcery.com
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20150506/f3c0e11f/attachment.html>