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

[David Vandevoorde]

> On May 6, 2015, at 9:49 AM, Richard Smith <richardsmith at googlers.com> wrote:
> 
> On 5 May 2015 at 18:17, Jason Merrill <jason at redhat.com <mailto: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 <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.

I think that’s a worthwhile addition to the mangling vocabulary.

	Daveed


>  
> 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 <mailto:cxx-abi-dev at codesourcery.com>
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev <http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev>
> 
> _______________________________________________
> cxx-abi-dev mailing list
> cxx-abi-dev at codesourcery.com <mailto:cxx-abi-dev at codesourcery.com>
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev <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/769483cb/attachment-0001.html>