This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch to fix PR9861
The demangler currently handles this by printing the return type as
the first argument of the method. I recognize that this is not ideal,
but it is a lot better than not seeing any decoded form at all. I
think Tom Tromey mentioned the option of doing something like what you
mentioned to work around the ambiguity.
What files need to be touched to fix the demangler to support this?
Would I be right in assuming that if we made a syntactic change like
this and fixed the demangler to support it, binutils and gdb would be
unable to decode the new form until the patches made it over to those
projects?
I'll fix the format of the code... Thanks for the tip.
TJ
On 22 Sep 2005 14:28:08 -0700, Ian Lance Taylor <ian@airs.com> wrote:
> TJ Laurenzo <tlaurenzo@gmail.com> writes:
>
> > The attached patch corrects PR9861 by including the return type in
> > mangled names in the C++ and Java compilers for Java class methods.
> > This changes the ABI for Java types but does not make any changes to
> > C++ programs that do not access Java types.
>
> How is the demangler going to work with this patch? Is there any way
> for the demangler to determine which names are Java names and which
> are C++ names? I don't see any obvious way, though I haven't looked
> that hard.
>
> If there is no way at present, then I recommend adding a 'J' at the
> start of bare-function-type if the return type is encoded. That is,
> do this:
> <bare-function-type> ::= [J] <type>+
> That should be unambiguous.
>
> (I note in passing that your patch is not formatted correctly
> according to the GNU standards. The correct formatting would be
> something like:
> mangle_ret_type = (!DECL_CONSTRUCTOR_P (decl)
> && !DECL_DESTRUCTOR_P (decl)
> && !DECL_CONV_FN_P (decl)
> && (decl_is_template_id (decl, NULL)
> || (DECL_FUNCTION_MEMBER_P (decl)
> && TYPE_FOR_JAVA (DECL_CONTEXT (decl)))));
> Thanks.)
>
> Ian
>