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