This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: EEEEKS! The mangling changed!


Carlo Wood <carlo@alinoe.com> writes:

[...]

| changed.  Nevertheless, the problem that I sketched exists.
| I propose to solve that problem by making an exception in the demanglers
| and let them produce "std::" instead of "__gnu_norm::".
| I am sure gdb will also be happy with that - or else they will have
| to do it themselfs (matching what the user types against __gnu_norm
| makes no sense). In fact, if you don't do this in the demangler, all
| debug tools will have to do the translation themselfs in a much more
| cpu consuming way.
| 
| The argument AGAINST this would be that the symbol *really* sits in

That is *one* argument.  We've not yet determined that there is one
true single argument we would call The Argument.

Does name mangling distinguish between implicit specializations and
explicit specializations?  (Some versions of EDG mangling did that in
the past but I don't think it was exproted to the common ABI)

There is one concern that shaped the design of the "namespace
association" functionality: that of uniquely identifying an explicit
specialization defined in std:: from anything else that would have
*appeared* as in std::.

The GDB issue was not explicitly taken into account during the
elaboration of "namespace association" though.

One may implement several hacks to try to accomodate that, but that
makes me nervous.  One of them being

   namespace __gnu_norm (__attribute__((alias("St")))) { }

or variants.  I don't like it because it is a clear indication of a
deficiency somewhere.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]