Discussion:
RFC: libiberty PATCH to disable demangling of ancient mangling schemes
Pedro Alves
2018-12-07 16:11:46 UTC
Permalink
Adding gdb-patches, since demangling affects gdb.

Ref: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00407.html
Looks good to me. Independently, do you see a reason not to disable the
old demangler entirely?
Like so. Does anyone object to this? These mangling schemes haven't
been relevant in decades.
I am not really familiar with this old scheme, so please excuse my ignorance
* How likely is it that there are old toolchain in use out there that still
use the v2 mangling ? Ie I guess that I am asking "which generation(s)
of gcc used v2 mangling ?"
GCC 3.0 and up used the new (Itanium C++ ABI) mangling, 2.95 and older used the old
mangling (2.96-RH used the new mangling I believe).
So you need compiler older than 17.5 years to have the old mangling.
Such a compiler didn't support most of the contemporarily used platforms
though at all (e.g. x86-64, powerpc64le, aarch64, I believe not even
powerpc64-linux).
Yeah.

I guess the question would be whether it is reasonable to expect
that people will still need to debug&inspect (with gdb, c++filt, etc.)
any such old binary, and that they will need to do it with with modern
tools, as opposed to sticking with older binutils&gdb, and how often
would that be needed.

I would say that it's very, very unlikely, and not worth it of the
maintenance burden.

Last I heard of 2.95-produced binaries I think was for some ancient gcc-2.95-based
cross compiler that was still being minimally maintained, because it was needed
to build&maintain some legacy stuff. That was maybe over 8 years ago, and
it was off trunk. It's probably dead by now. And if isn't dead,
whoever maintains the compiler off trunk certainly can also maintain old-ish
binutils & gdb off trunk.

Thanks,
Pedro Alves
Tom Tromey
2018-12-07 17:48:58 UTC
Permalink
Pedro> I would say that it's very, very unlikely, and not worth it of the
Pedro> maintenance burden.

Agreed, and especially true for the more unusual demanglings like Lucid
or EDG.

On the gdb side perhaps we can get rid of "demangle-style" now. It
probably hasn't worked properly in years, and after this it would be
guaranteed not to.

Tom
Jason Merrill
2018-12-07 21:00:41 UTC
Permalink
Post by Tom Tromey
Pedro> I would say that it's very, very unlikely, and not worth it of the
Pedro> maintenance burden.
Agreed, and especially true for the more unusual demanglings like Lucid
or EDG.
On the gdb side perhaps we can get rid of "demangle-style" now. It
probably hasn't worked properly in years, and after this it would be
guaranteed not to.
So, here's the patch to tear out the old code, which passes the GCC
regression testsuite. I also tried building binutils/gdb with it, and
both will need to remove code that calls cplus_mangle_opname for dealing
with the old mangling scheme.

Jason

Loading...