Patch to fix PR9861

TJ Laurenzo tlaurenzo@gmail.com
Tue Sep 27 13:57:00 GMT 2005


On 9/27/05, Andrew Haley <aph@redhat.com> wrote:
> 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.

Ok.  The space goes.  A single observation on this point is that
methods with more than one argument have a space between the comma and
beginning of the next argument.  With that said, in light of the the
common case of a method with <=1 arguments I can see how it makes
sense for the demangled name to not include a space.

The decision to exclude return types on constructors was based on a
list of C++  rules for excluding return types for members of template
classes.  It seemed to make since, so I did the same thing with Java. 
The return type for constructors shows up as "void" in the tree, so
including it would put a "v" at the end of every demangled name and
add a "Jv" to each mangled form.  I'm inclined to keep the exclusion
because it sticks with the existing rule that in C++, constructors
never have an encoded return type.

TJ



More information about the Gcc-patches mailing list