Re: confusion in the `b' command

[Daniel Jacobowitz <drow@mvista.com>]

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