Some java questions

Some java questions

[Keith Seitz]

Hi,

I've been mucking with Daniel's DWARF2 "full names" patch, and a number 
issues with java and the gdb.java/jmisc.exp and gdb.java/jprint.exp 
tests have appeared.

Both of these test cases have the following comment:

     # Ref PR gdb:java/1565.  Don't use the simpler "break jmisc.main".
     # As of 2004-02-24 it wasn't working and is being tested separatly.
     # Before GCJ 4.1 (approximately) the demangled name did not include
     # a method signature; after that point it does include a trailing
     # signature.

In the case of jmisc,exp, the test suite attempts to set breakpoints on 
"'jmisc.main(java.lang.String[])'" and 
"'jmisc.main(java.lang.String[])void'", working around the gcc bug 
(similar in jprint.exp). IMO, this is a very dangerous precedent. Bugs 
in the toolchain should not be worked around like this. They should be 
xfailed or (in this case), breaks at the correct "jmisc.main" should 
have been left in as well.

IMO this bug should be closed/not-a-bug, and jmisc/jprint.exp should be 
"fixed". [There are several ways this could be done. The simplest is to 
simply break at "jmisc.main" as it should. Maybe add 
"jmisc.main(java.lang.String[])" as a back-up. If someone recommends a 
course of action, I would be happy to follow it up.]

But that's not my real concern. What puzzles me is this second function 
"jmisc.main(java.lang.String[])void". What the heck is that, 'cause it 
isn't java. It looks to me like some partially demangled java method 
signature (which is still not valid input to a java compiler).

I also note this in "info func":

(gdb) info func jmisc
All functions matching regular expression "jmisc":

File /tmp/ccozBSfv.jar:
void jmisc.jmisc();
void jmisc.main(java.lang.String[])void;

Now maybe my java is really rusty after two months, but I'm pretty sure 
"void jmisc.main(java.lang.String[])void;" is not a valid method 
declaration.

What's puzzling about all of this is that the gcc/gdb versions which 
java/1565 affect actually show something sane:

(old-gdb) info func jmisc
All functions matching regular expression "jmisc":

File jmisc.java:
void jmisc.jmisc();
void jmisc.main(java.lang.String[]);

While it is true that one cannot "break jmisc.main" on those "broken" 
versions, one can simply do "break jmisc.main(java.lang.String[])". Any 
attempt to tack on the "void" either results in a "junk at end of 
argument list" error (without surrounding ') or a "make pending 
breakpoint?" query (with surrounding ' -- breakpoint never gets hit).

At long last, my question is: Is gdb supposed to be able to do something 
with "jmisc.main(java.lang.String[])void", i.e. is it considered valid 
"input" to break, print, and other commands?

Keith

Re: Some java questions

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:

Keith> But that's not my real concern. What puzzles me is this second
Keith> function "jmisc.main(java.lang.String[])void". What the heck is that,
Keith> cause it isn't java. It looks to me like some partially demangled java
Keith> method signature (which is still not valid input to a java compiler).

To support Java 1.5, we had to add return types to name mangling.
These are needed due to covariant return types.

What you are seeing here is just how the demangler chooses to print
this information.  E.g., when I 'nm --demangle=java' a simple java
program, I see:

0804891e T h.main(java.lang.String[])void
         U java.lang.Object.toString()java.lang.String
[etc]

Keith> At long last, my question is: Is gdb supposed to be able to do
Keith> something with "jmisc.main(java.lang.String[])void", i.e. is it
Keith> considered valid "input" to break, print, and other commands?

FYI -- nobody really maintains the gcj support in gdb.

It would be nice to be able to break on a method that can only be
differentiated by its return type.  Normally, though, I think only one
of the methods like this really matters -- the rest are just bridge
methods and probably not interesting.  It might be tricky for gdb to
sort this out though.

Tom

Re: Some java questions

[Daniel Jacobowitz]

On Tue, Sep 09, 2008 at 12:43:27PM -0700, Keith Seitz wrote:
> In the case of jmisc,exp, the test suite attempts to set breakpoints on  
> "'jmisc.main(java.lang.String[])'" and  
> "'jmisc.main(java.lang.String[])void'", working around the gcc bug  
> (similar in jprint.exp). IMO, this is a very dangerous precedent. Bugs in 
> the toolchain should not be worked around like this. They should be  
> xfailed or (in this case), breaks at the correct "jmisc.main" should have 
> been left in as well.

See jmain.exp, which is specifically for this issue.

> At long last, my question is: Is gdb supposed to be able to do something  
> with "jmisc.main(java.lang.String[])void", i.e. is it considered valid  
> "input" to break, print, and other commands?

As long as it appears in the mangling - and gcj is going to continue
emitting DW_AT_MIPS_linkage_name, which I expect it will - I think it
ought to work.  Particularly with single quotes around it, as
jmisc.exp uses.

On Tue, Sep 09, 2008 at 03:17:52PM -0600, Tom Tromey wrote:
> FYI -- nobody really maintains the gcj support in gdb.

This is sad, but very much true.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Some java questions

[Keith Seitz]

Daniel Jacobowitz wrote:
>> At long last, my question is: Is gdb supposed to be able to do something  
>> with "jmisc.main(java.lang.String[])void", i.e. is it considered valid  
>> "input" to break, print, and other commands?
> 
> As long as it appears in the mangling - and gcj is going to continue
> emitting DW_AT_MIPS_linkage_name, which I expect it will - I think it
> ought to work.  Particularly with single quotes around it, as
> jmisc.exp uses.

After reading Tom's note, things make some sense. I don't like it much, 
but, well, that's the way it is. I'm glad I don't have to use gdb with 
Java any more!

I will fix the failing test case as it is. I'll revisit how this all 
*should* work when (or if) I attempt to eradicate MIPS_linkage_name 
altogether.

Keith

Re: Some java questions

[Keith Seitz]

Tom Tromey wrote:

> To support Java 1.5, we had to add return types to name mangling.
> These are needed due to covariant return types.

Ah, okay, that explains a lot.

> What you are seeing here is just how the demangler chooses to print
> this information.  E.g., when I 'nm --demangle=java' a simple java
> program, I see:
> 
> 0804891e T h.main(java.lang.String[])void
>          U java.lang.Object.toString()java.lang.String
> [etc]

Yuck. Nonetheless, it looks like that's the status quo, and I need to 
fix it. I'll also look into either fixing the "info func" printout or at 
least add a test case for that so that it doesn't disappear.

Keith