This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

fix break, not add future-break


Hello,

There is a change kicking around that adds a new `future-break' command. It started life as `save breakpoints':

http://sources.redhat.com/ml/gdb-patches/2001-12/msg00108.html

that received a prompt review response. Unfortunatly, instead of simply addressing the relevant issues, it turned into a future-break jumbo patch:

http://sources.redhat.com/ml/gdb-patches/2001-12/msg00296.html

At the time Tom Tromey made the point:

Klee> The 'future-break' command allows one to specify a breakpoint
Klee> that starts off as 'shlib_disabled' instead of generating an
Klee> error if it can't be set immediately.

Klee> I'm not entirely happy with the future-break command, and
Klee> particularly with its interaction with the save-breakpoints
Klee> mechanism (if you set a breakpoint that is in a shared library
Klee> after shared libraries have been loaded, you have to remember to
Klee> use the future-break command, not the break command).

Doesn't this mean that programs like Insight would be best advised to
*only* set future breakpoints?  In that case let's just add the
functionality directly to the existing breakpoint commands.
http://sources.redhat.com/ml/gdb-patches/2001-12/msg00152.html

(the original contributor never responded.)

I think Tom is right. Rather than adding a new contextually sensitive command (`don't mode me in'), GDB should `fix' the existing break command. Just like the GUI, normal users are going to be confused by this unnecessary choice. Why, after all, should a user have to learn a different command just so that they can set breakpoints on an unloaded shared library?

Further, if GUI implementors want specific break command semantics, then they should be extending the MI interface and not perverting the CLI.

I'd like to propose that break be modified so that it behaves something like:

	(gdb) break printf.c:printf
	File "printf.c" not currently known, set breakpoint anyway?

And then later:

	(gdb) c
	Loading shared library libc.so.
	Enabling breakpoint "printf.c:printf" at ....

For edge conditions:

- If the executable is re-started or re-loaded, all breakpoints get marked as `unloaded' (or what ever shlib breakpoints are ment to get set to) and then get enabled as they become valid.
- If it turns out that a breakpoint is never enabled then `oops'.
- If it turns out that a breakpoint wasn't valid, issue a warning and disable it for the remainder of that session (?).
- If a breakpoint isn't valid in a script, then issue a warning and add it anyway. Who's it going to hurt?
- if the executable being debugged is changed then, well, do what ever the current code does.


Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]