Re: Patch to fix PR9861

[Andrew Haley <aph at redhat dot com>]

Andrew Haley writes:
 > TJ Laurenzo writes:
 >  > On 9/26/05, Bryce McKinlay <mckinlay@redhat.com> wrote:
 >  > > Andrew Haley wrote:
 >  > >
 >  > > >Ian Lance Taylor writes:
 >  > > > > Andrew Haley <aph@redhat.com> writes:
 >  > > > >
 >  > > > > > How about simply
 >  > > > > >
 >  > > > > >  f.main(String[])void
 >  > > > > >
 >  > > > > > That's the nearest to the Java signature form.
 >  > > > >
 >  > > > > I don't know, it's kind of ugly and confusing.
 >  > > >
 >  > > >Looks OK to me, but maybe that's a Java thing.  Or maybe I'm weird.
 >  > > >
 >  > > >
 >  > > I'll also cast a vote for this form - it is the simplest and most Java
 >  > > like. I don't like the ":".
 >  > 
 >  > The patch for this is attached (fix-java-demangle.diff).  I added a
 >  > flag DMGL_RET_POSTFIX for the demangler.  When this flag is present,
 >  > the return type is output after the function signature with a space
 >  > separating the two.  This option is enabled by default for the Java
 >  > demangler.  I modified the test harness and added test cases for this
 >  > as well.  This patch applies against cvs head, so it replaces the
 >  > libiberty parts of my previous patch.
 >  > 
 >  > I am also attaching a patch to gdb that uses this new flag to put
 >  > return types after the function signature for normal C++ symbols
 >  > stored in the lookup table too.
 > 
 >  > This helps with CNI debugging and as a consequence, works around
 >  > the issue that was pointed out earlier with selecting template
 >  > functions.  I'm not terribly familiar with gdb internals, so I am
 >  > not certain if this second patch causes any other problems or
 >  > whether the maintainers want to change the behavior for template
 >  > functions.
 > 
 > OK.  We'll see.
 > 
 > I'm not keen on the space, but it's not important enough to reject
 > your patch.

I changed my mind because the space makes assembly expressions look
really odd.  Like this:

-----------------------------------------------------------------------
.globl Test.x() java.lang.Object
        .type   Test.x() java.lang.Object, @function
Test.x() java.lang.Object:
.LFB3:
.LBB3:
        movl    $0, %eax
.LBE3:
        ret
.LFE3:
        .size   Test.x() java.lang.Object, .-Test.x() java.lang.Object
-----------------------------------------------------------------------

If you remove the space, it's much clearer that
"Test.x()java.lang.Object" is a single symbol:

-----------------------------------------------------------------------
.globl Test.x()java.lang.Object
        .type   Test.x()java.lang.Object, @function
Test.x()java.lang.Object:
.LFB3:
.LBB3:
        movl    $0, %eax
.LBE3:
        ret
.LFE3:
        .size   Test.x()java.lang.Object, .-Test.x()java.lang.Object
-----------------------------------------------------------------------

Also, constructors have no encoded return type.  I guess that's OK,
but I was rather surprised.

Andrew.