Re: Patch to fix PR9861

[Andrew Haley <aph at redhat dot com>]

TJ Laurenzo writes:
 > 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.
 > >
 > 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.

Yes.  This means that you can't set a breakpoint on
'main(java.lang.String[])'.  The only way you can set a breakpoint is
if you know the mangled string.

 > 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.

It does.  However, it might be possible to persuade people to ship
updated bnutils on free operating systems.  Unfree systems are going
to be much more problematic, though.

 > 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.

I don't think we can live with that!  :-)

 > 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.

Andrew.