Re: [cxx-abi-dev] Name mangling for explicit overriders

[Christophe de Dinechin <ddd@xxxxxxxxxx>]

Mark,


I think that adding a vendor-specific namespace is a good idea. It 
makes it possible for an arbitrary demangler to emit something like 
"_Zxxx... (EDG extension)".
What remains unclear is what you are allowed to do with such symbols. 
In the EDG / MS extension example given, is there any implication 
regarding this-pointer adjustment? Is a third-party linker allowed to 
process object files with such vendor-specific extensions? What kind of 
link-time optimizations are prevented by the presence of such a special 
symbol? If you can't link them, then you might as well mark the object 
as belonging to another ABI...
Also, making the "extension tag" a prefix of the whole symbol means 
that you can't demangle anything. What about combining your idea with 
the EDG approach and reserving "O" for extensions? So you'd have 
something like Ov3EDG <length> <vendor-specific>, so that any demangler 
could show something like "D::f [with an EDG-specific extension]", and 
the EDG demangler would show "D::f [overriding B2::f]" as proposed.
I also really appreciate that EDG tries to make sure that even their 
proprietary extensions are known to the rest of the ABI users. I 
recommend that we keep track of such extensions in the document when 
vendors are kind enough to share them. What about an appendix to the 
ABI?

Regards
Christophe

On Sunday, Jul 27, 2003, at 20:24 Europe/Paris, Mark Mitchell wrote:

> On Sun, 2003-07-27 at 05:21, J. Stephen Adamczyk wrote:
> > We recently implemented the Microsoft extension that allows explicit
> > specification of overriding on derived class virtual functions.
> > For example:
> >
> > 	struct B1 {
> > 	  virtual void f() = 0;
> > 	};
> > 	struct B2 {
> > 	  virtual void f() = 0;
> > 	};
> > 	struct D: B1, B2 {
> > 	  virtual void B1::f() {}  // Overrides B1::f (only)
> > 	  virtual void B2::f() {}  // Overrides B2::f (only)
> > 	};
> >
> > (Hey, we didn't invent it; we're just implementing it for Microsoft
> > compatibility. :-) )
> >
> > This has a name mangling implication: as shown in the above example,
> > you can end up with two member functions in a given class that have
> > the same name and signature, and differ only in the function that
> > they override.
> >
> > Here's the extension we made to name mangling, so that others who
> > have to do this feature might do it the same way, or so that anyone
> > who sees a problem with what we did can warn us now before we ship
> > it.
> >
> > We added a rule for <encoding>:
> >
> >   <encoding> ::= <function name> O <nested-name> <bare-function-type>
> I've suggested before that we should have a portion of the mangling
> namespace (i.e., the names that begin with "_Z") reserved for vendor
> extensions.
>
> I'm not 100% sure that the following scheme will not conflict with
> anything else, but it will serve as an illustration:
>
>   _Z v <length number> <vendor identifier> ...
>
> The idea is that all EDG-specific manglings would begin with:
>
>   _Zv3EDG
>
> The characters that follow that point would be entirely up to you.
>
> That would keep the manglings that you add from getting in the way of
> any future extensions of the base standard.  In other words, if some 
> new
> feature C++ 2017 caused us to add a mangling, we wouldn't have to
> remember that EDG is already using this bit with the "O" in the middle
> of it for this Microsoft thing.
>
> What do you think of this idea?  What do other people think?
>
> --
> Mark Mitchell
> CodeSourcery, LLC
> mark@xxxxxxxxxxxxxxxx