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 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 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 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 (gdb) c Continuing. Breakpoint 3, 0x20000000000ec5e0 in printf () from /lib/tls/libc.so.6.1 (gdb)