Re: Patch to fix PR9861

[TJ Laurenzo <tlaurenzo at gmail dot com>]

On 9/26/05, Andrew Haley <aph@redhat.com> wrote:
> TJ Laurenzo writes:
>  > Andrew Haley wrote:
>  > > I wonder what this does to debugging.  I'm going to try it now.
>  >
>  > If you build gdb with the patched cp-demangle.c the only difference
>  > *should* be that demangled names will include the return type (without
>  > cp-demangle.c patched, you will only see mangled names).  I have not
>  > tested this against gdb so I am interested to know how it goes.
>  >
>  > I have tested this against binutils by applying the cp-demangle.c
>  > patch and verifying that demangling names in object files works
>  > properly (ie.  nm -C).  I have also added a couple of test cases to
>  > libiberty that exercise this change.
>
> We're going to need to be able to run with an unpatched gdb and an
> unpatched binutils for a little while.  I understand that there may be
> some odd behaviour, but basic debugging must still be possible.
>
> Andrew.
>
>
The current "odd" behavior in an unpatched binutils is that anytime it
tries to demangle the name, it will fail and only print the mangled
name.  I would expect similar behavior from GDB (except that in GDB,
the lack of demangling would really complicate things more than the
same lack in binutils).  So, my opinion is that GDB is the main
problem here, since this patch effectively makes Java debugging very
difficult with an unpatched GDB.

I will note that with my original patch, both tools would print
demangled names but the return type would be listed as the first
parameter.  In addition to being odd, this also has other problems
that Ian pointed out.

If we could find an encoding format that was recognized by the current
demangler and provided uniqueness guarantees consistent with the new
patch, this could work.... perhaps a flag character somewhere that the
current demangler would ignore instead of abort on.

TJ