Re: three notes on setting breakpoints

[James Ingham <jingham at cygnus dot com>]

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