confusion in the `b' command

confusion in the `b' command

[Tom Tromey]

I'm using x86 Red Hat Linux 6.2.

Compile the appended java program (probably any program will do) like
this:

    gcj --main=x -g -o x x.java

Now debug it with the latest cvs trunk gdb:

    gdb -nw ./x

Now try to set a breakpoint like this:

    b 'x.main<TAB>

gdb just beeps at me.
So close the quotes and press enter:

    (gdb) b 'x.main'
    the class x does not have any method named main
    Hint: try 'x.main'<TAB> or 'x.main'<ESC-?>
    (Note leading single quote.)

Now try again:

    b 'x.main<TAB>

I get:

    (gdb) b 'x.main(java.lang.String[])' 

I think this must be a bug.  I expected:

* First, that TAB would work correctly the first time.

* Second, that b 'x.main' would work anyway, since it is unambiguous.
  (I only found the first bug because gdb has basically been forcing
  me to hit TAB all along...)

Tom

import java.net.*;
public class x
{
  public static void main (String[] args) throws Throwable
  {
    String x = "core:/zardoz.properties";
    URL u = new URL (x);
    System.out.println (u.getFile ());
  }
}

Re: confusion in the `b' command

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Date: 22 Apr 2002 13:43:10 -0600
> 
> Now try to set a breakpoint like this:
> 
>     b 'x.main<TAB>
> 
> gdb just beeps at me.

What version of GDB is that?  Head? branch? released version?

> So close the quotes and press enter:
> 
>     (gdb) b 'x.main'
>     the class x does not have any method named main
>     Hint: try 'x.main'<TAB> or 'x.main'<ESC-?>
>     (Note leading single quote.)
> 
> Now try again:
> 
>     b 'x.main<TAB>
> 
> I get:
> 
>     (gdb) b 'x.main(java.lang.String[])' 
> 
> I think this must be a bug.  I expected:
> 
> * First, that TAB would work correctly the first time.

This is probably another manifestation of a known problem with
completion: different types of objects (files, symbols, commands,
etc.) need different sets of delimiter characters to make completion
DTRT, but Readline doesn't give GDB a chance to set the delimiters
before the first completion attempt.  Thus, GDB gets the user input
after breakup into words, but the notion of ``a word'' does not match
what it should be for the object on which GDB is completing.

We currently try to work around this nuisance, but there's no way to
do that for the first completion attempt on a given object type.z

What we need is a hook from Readline that would be called _before_
Readline breaks up input into ``words''.

> * Second, that b 'x.main' would work anyway, since it is unambiguous.

I'm not sure what you mean here.  Do you mean that GDB shouldn't have
forced you to quote the string "x.main(java.lang.String[])"?

Re: confusion in the `b' command

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:

Eli> What version of GDB is that?  Head? branch? released version?

Latest cvs trunk gdb.  (That was in my email, albeit buried a bit.)

>> * Second, that b 'x.main' would work anyway, since it is unambiguous.

Eli> I'm not sure what you mean here.  Do you mean that GDB shouldn't have
Eli> forced you to quote the string "x.main(java.lang.String[])"?

I shouldn't even have to type `(java.lang.String[])' at all.
`b x.main' is unambiguous.  There is only one `main' method in the
class `x'.

Tom

Re: confusion in the `b' command

[Eli Zaretskii]

On 22 Apr 2002, Tom Tromey wrote:

> >>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
> Eli> What version of GDB is that?  Head? branch? released version?
> 
> Latest cvs trunk gdb.  (That was in my email, albeit buried a bit.)

Yes, it was buried, sorry for not paying attention.

It's probably a good idea to see if that isn't some regression due to 
latest changes.  I have several versions of GDB going back as far as 
4.18, but unfortunately I have no gcj installed anywhere.

> >> * Second, that b 'x.main' would work anyway, since it is unambiguous.
> 
> Eli> I'm not sure what you mean here.  Do you mean that GDB shouldn't have
> Eli> forced you to quote the string "x.main(java.lang.String[])"?
> 
> I shouldn't even have to type `(java.lang.String[])' at all.
> `b x.main' is unambiguous.  There is only one `main' method in the
> class `x'.

I think the punctuation characters prevent that.  But it could also be a 
bug or regression.  One possible way to find out is to try this with 
commands that complete only on symbols (`b' completes on ``locations'', 
which could include file names and line numbers, so it's more complicated 
and thus more bug-prone).

Sorry I can't do that myself, for the lack of gcj.

Re: confusion in the `b' command

[Daniel Jacobowitz]

On Mon, Apr 22, 2002 at 01:43:10PM -0600, Tom Tromey wrote:
> I'm using x86 Red Hat Linux 6.2.
> 
> Compile the appended java program (probably any program will do) like
> this:
> 
>     gcj --main=x -g -o x x.java
> 
> Now debug it with the latest cvs trunk gdb:
> 
>     gdb -nw ./x
> 
> Now try to set a breakpoint like this:
> 
>     b 'x.main<TAB>
> 
> gdb just beeps at me.
> So close the quotes and press enter:
> 
>     (gdb) b 'x.main'
>     the class x does not have any method named main
>     Hint: try 'x.main'<TAB> or 'x.main'<ESC-?>
>     (Note leading single quote.)
> 
> Now try again:
> 
>     b 'x.main<TAB>
> 
> I get:
> 
>     (gdb) b 'x.main(java.lang.String[])' 
> 
> I think this must be a bug.  I expected:
> 
> * First, that TAB would work correctly the first time.
> 
> * Second, that b 'x.main' would work anyway, since it is unambiguous.
>   (I only found the first bug because gdb has basically been forcing
>   me to hit TAB all along...)

These are caused by assumptions in GDB and in the demangler that the
class separator is '::' instead of '.'.  Try "b 'y::main<TAB>" and it
will complete correctly the first time.  We need to be more flexible
about this.  In Java mode, we probably want to recognize both
separators...

The second problem is related to the incorrect debug info we were
discussing earlier.  Witness:

(top-gdb) p $32.type.core_type.type_specific.cplus_stuff.fn_fieldlists[0]
$39 = {name = 0x829521b "y.main(java.lang.String[])", length = 1, fn_fields = 0x82b812c}

The name of the method should be simply "main" in the debug info for
the type.  Not much GDB can do while that is still wrong.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer