three notes on setting breakpoints

three notes on setting breakpoints

[Tom Tromey]

Today I'm an Insight bug-reporting machine.  I'm using it to debug gcj
(the Java front end to gcc), and sometimes stubs I'm generating from
gcj, both of which are fairly nasty tests.

Hey, Jim -- don't feel like you have to reply to all of these
messages.  I'm assuming you're noting them for the happy day that you
can spend doing Insight hacking.

(First, I noticed that Insight saves my command-line arguments between
sessions.  This is cool!  I wish it saved them based on the exec file,
though, because I have a different set of arguments when I debug the
other program I'm working on today.  This is note #1.)

gcj has two files named "expr.c" -- gcc/expr.c and gcc/java/expr.c.  I
want to set a breakpoint on `build_jni_stub', my new function in
gcc/java/expr.c.  I decided to try, this time, to live without the
console if I could.

So, I went to the source window and used the combobox in the lower
left to show expr.c.  It shows the "wrong" (for my purposes) expr.c.
There is apparently no way to convince it to show the right one.  That
means I can't find the function I want to set a breakpoint on it.

Ideally I'd like to see "expr.c" and "java/expr.c" in the combobox.
Even seeing "expr.c" twice would be ok.  ISTR that getting the right
information out of gdb here is a pain though.  (Note #2.)

Also, I noticed that the contents of the function combobox are not
sorted alphabetically.  They almost are.  I don't understand what I'm
seeing, because they also aren't in the order they appear in the
source file.  They are sorted from clear_pending_stack_adjust to
use_regs, and then sorted from clear_by_pieces to var_rtx.  Weird.
(Note #3.)

The breakpoint window doesn't provide me with a way to set an
arbitrary breakpoint.  So in my case I seem to be forced to use the
Console window -- which I understand isn't all that well supported :-(
(Ok, note #4, which I didn't mention in the subject.)

Tom

Re: three notes on setting breakpoints

[James Ingham]

Tom,

 > Today I'm an Insight bug-reporting machine.  I'm using it to debug gcj
 > (the Java front end to gcc), and sometimes stubs I'm generating from
 > gcj, both of which are fairly nasty tests.

Cool...

 > 
 > Hey, Jim -- don't feel like you have to reply to all of these
 > messages.  I'm assuming you're noting them for the happy day that you
 > can spend doing Insight hacking.

Yup.

 > 
 > (First, I noticed that Insight saves my command-line arguments between
 > sessions.  This is cool!  I wish it saved them based on the exec file,
 > though, because I have a different set of arguments when I debug the
 > other program I'm working on today.  This is note #1.)

Yeah, we need to save preferences both based on executable, and on
architecture, since you can do things like eliminate registers that
you don't want to see from the display, and that will get saved
(thanks Steve!) but if you work on different processors, and you
happen to want to hide a register in one but not in the other you are
hosed right now. 

 > 
 > gcj has two files named "expr.c" -- gcc/expr.c and gcc/java/expr.c.  I
 > want to set a breakpoint on `build_jni_stub', my new function in
 > gcc/java/expr.c.  I decided to try, this time, to live without the
 > console if I could.
 > 
 > So, I went to the source window and used the combobox in the lower
 > left to show expr.c.  It shows the "wrong" (for my purposes) expr.c.
 > There is apparently no way to convince it to show the right one.  That
 > means I can't find the function I want to set a breakpoint on it.
 > 
 > Ideally I'd like to see "expr.c" and "java/expr.c" in the combobox.
 > Even seeing "expr.c" twice would be ok.  ISTR that getting the right
 > information out of gdb here is a pain though.  (Note #2.)

This is gdb getting confused, not insight, since insight just does
info files and puts the results into the combo box.

 > 
 > Also, I noticed that the contents of the function combobox are not
 > sorted alphabetically.  They almost are.  I don't understand what I'm
 > seeing, because they also aren't in the order they appear in the
 > source file.  They are sorted from clear_pending_stack_adjust to
 > use_regs, and then sorted from clear_by_pieces to var_rtx.  Weird.
 > (Note #3.)

Humm...  Not sure about this.

 > 
 > The breakpoint window doesn't provide me with a way to set an
 > arbitrary breakpoint.  So in my case I seem to be forced to use the
 > Console window -- which I understand isn't all that well supported :-(
 > (Ok, note #4, which I didn't mention in the subject.)

The console IS supported for those things that aren't supported in the 
GUI yet.  Among those is the ability to set arbitrary breakpoints, and 
to add conditions, ignore counts & actions.  These will all track with 
the GUI.  But I agree, we need both a quick teeney dialog to just type 
in a breakpoint that you can get to really easily, and then the
ability to enter more complicated breakpoints in the breakpoints
window.  These two are high on my list of "features to add", but I am
trying to restrain myself from adding features till I have slain all
the bugs that really bother me...

Jim

-- 
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham                                              jingham@cygnus.com
Cygnus Solutions, a Red Hat Company                      

Re: three notes on setting breakpoints

[Tom Tromey]

>> Also, I noticed that the contents of the function combobox are not
>> sorted alphabetically.  They almost are.

Jim> Humm...  Not sure about this.

I looked at the code.
It looks like gdb_listfuncs (gdbtk-cmds.c) does not return the
functions in alphabetical order.  Instead it returns them in
alphabetical order on a per-block basis (not sure what a block is --
see sort_block_syms()).
I think instead it should do the sort globally.

Tom

Re: three notes on setting breakpoints

[Steven Johnson]

James Ingham wrote:

> Yeah, we need to save preferences both based on executable, and on
> architecture, since you can do things like eliminate registers that
> you don't want to see from the display, and that will get saved
> (thanks Steve!) but if you work on different processors, and you
> happen to want to hide a register in one but not in the other you are
> hosed right now.
> 

I was thinking on this this weekend. The Idea I came up with is a list of
different configurations.
Such that you go into config and select from the list the config you want.
Then all of the preferences
would be reloaded. Preferences would be of the form "$ConfigName/Preference".
If no custom config was selected then
the preferences would remain as they are now. This is also something that
needs to be done. Id prefer something like this over
tying it to executable as you may want different debug contexts for the same
executable. Or more likely, the same debug context for different executables.
Ideally there would also be a command line parameter to select the default
configuration.

Steven.