[WIP] pending breakpoint support

J. Johnston jjohnstn@redhat.com
Wed Nov 19 01:03:00 GMT 2003


I have been hacking around with supporting "future-break" functionality (note, I 
said "hacking").  I have seen past discussion regarding the issue and the 
requirement to add functionality to the current breakpoint command as opposed to 
creating a separate command.

For my change, I wrappered the call to parse_breakpoint_sals() to catch any 
error.  If the call fails, then I simply give the user the option as marking it 
as pending.  I then make a fake breakpoint with a special enable_state of 
bp_shlib_pending.  I also save the original breakpoint command as the 
addr_string plus some needed state to recreate the command at a later time.  I 
attempted to have any original condition parsed but it isn't used in my current 
design as I end up reparsing the original command from scratch anyway.

When we are loading shared libraries, the function 
re_enable_breakpoints_in_shlibs() gets called.  I have added code in there to 
attempt to reparse any pending break command.  If successful, a new breakpoint 
is created by basically reissing the command with saved state accounted for. 
After creating the new breakpoint(s), I delete the pending place holder breakpoint.

Ideally, I would liked to have reused the same breakpoint structure that was 
initially allocated but in my code there still was the possibility of one 
command generating multiple breakpoints so I took the aforementioned strategy. 
I have been informed that the newer breakpoint model will eliminate that problem 
and I should be able to reuse the breakpoint number, etc...

A problem I didn't solve yet has to do with the issuing of error messages for 
pending and disabled shared-library breakpoints when the reenablement is 
attempted and it fails.  This can be very annoying when you have a large number 
of shared libraries loaded each time (e.g. Eclipse).

I have included a gdb session below along with the patch I used so folks can see 
how it currently works.

What I would like to do is get some discussion going:

   1. Is the user interface on the right track?
   2. What gotchas do I need to think about?
   3. Any design recommendations for implementing this better?

-- Jeff J.

/../gdb -nw a.out
GNU gdb 2003-11-07-cvs
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "ia64-unknown-linux-gnu"...Using host libthread_db 
library "/lib/tls/libthread_db.so.1".

(gdb) b printf
Function "printf" not defined.
Make breakpoint pending? (y or n) y
Breakpoint 1 (printf) pending.
(gdb) info break
Num Type           Disp Enb Address            What
1   breakpoint     keep n   <PENDING>          printf
(gdb) b main
Breakpoint 2 at 0x4000000000000702: file hello.c, line 9.
(gdb) info break
Num Type           Disp Enb Address            What
1   breakpoint     keep n   <PENDING>          printf
2   breakpoint     keep y   0x4000000000000702 in main at hello.c:9
(gdb) run
Starting program: 
/to/scratch/jjohnstn/gdb-patches/future-break/build/ia64/gdb/testsuite/gdb.base/a.out 

Pending breakpoint <printf> resolved
Breakpoint 3 at 0x20000000000ec5e0

Breakpoint 2, main () at hello.c:9
9	   x = printf ("hello world\n");
(gdb) info break
Num Type           Disp Enb Address            What
2   breakpoint     keep y   0x4000000000000702 in main at hello.c:9
	breakpoint already hit 1 time
3   breakpoint     keep y   0x20000000000ec5e0 <printf+48>
(gdb) c
Continuing.

Breakpoint 3, 0x20000000000ec5e0 in printf () from /lib/tls/libc.so.6.1
(gdb)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pending-break.patch
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20031119/52d5f907/attachment.ksh>


More information about the Gdb-patches mailing list