This is the mail archive of the gdb-patches@sourceware.org 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]

[0/9] Breakpoints at multiple locations


At the moment, gdb assumes that a code breakpoint has
a single PC value. One case where it does not work
is C++ constructors -- GCC generates several function
bodies, and GDB sets breakpoint on just one of them,
so breakpoints in constructors don't work reliably.
Another case is C++ templates -- if I set a breakpoint
on a line in template function, there's unbounded number
of template instantiations that have this line, but GDB
cannot set breakpoints on all of them.

I'm about to post a set of patches that fix it. Essentially,
the patches make breakpoint have a list of breakpoint locations.
When a breakpoint is creates, GDB automatically figures out the
set of locations to use. User can than disable locations that seem
uninteresting to him.

GDB can also handle locations in shared libraries. Suppose you
have breakpoint at foo.hpp:10, which is a template function.
Then, when new shared library is loaded, gdb will figure out
if there is any code in the library corresponding to foo.hpp:4.
If now, the list of locations for the breakpoint will be updated.

As a side effect, this set of patches simplifies internal handling
of pending breakpoints. Since we need the code to recompute all
locations when a shared library is loaded, there's no need to special-case
pending breakpoints, so now pending breakpoint is a breakpoint without
any locations.  Importantly, when pending breakpoint is resolved, it
no longer gets a new number, which should make MI frontends a little
bit happier.

The patches has direct effect on two user commands. The "info break"
now outputs multiple locations, if they are present, like this:

        Num Type           Disp Enb  Address    What
        1   breakpoint     keep y    <MULTIPLE>
        1.1                     y    0xb7fa756d in int bar<int>(int) at helper.hpp:4
        1.2                     y    0xb7fa7588 in double bar<double>(double) at helper.hpp:4


The output for a breakpoint with single location is not changed. 

The display of pending breakpoints is improved. In CVS HEAD as it is now, 
breakpoint internally has three important states:

	- enabled
	- disabled
	- shlib_disabled

Breakpoint enters the last state when the library it is in is unloaded. 
User can never explicitly specify this state. Unfortunately, user can 
explicitly leave this state, using the 'enable' command. The result will be
an error on next resume -- as gdb will try to insert this breakpoint, in
an unloaded library. My patches explicitly separate "enabled/disabled" state,
which can be changed by user, and the "pending" state -- which means that
this breakpoint is not in a loaded code yet, and won't fire yet. The pending
state is maintained by gdb. The display is adjusted accordingly -- 
for pending breakpoints we show "(p)" after "y" or "n", for example:

        1   breakpoint     keep y    <MULTIPLE>
                breakpoint already hit 2 times
        1.1                     y(p) 0xb7f9856d helper.hpp:4
        1.2                     n(p) 0xb7f98588 helper.hpp:4

means that user wants location 1.1 to be enabled, and wants location 1.2
to be disabled. The "(p)" means that both are in unloaded shared library,
so naturally 1.1 won't be hit until the library is loaded.

In addition to "info break" changes, the "enable" and "disable" commands
were modified to accept locations, so:

	disable 1.2 

will disable second location of breakpoint 1.

Since the original patch was about 100K and non-intelligible, it was
split in 9 separate patches. Each leaves gdb without regressions and
some patches have a value on their own.

	1. Remove stale code in update_breakpoints_after_exec
	2. Remove the 'silent' parameter in disable_breakpoints_in_shlibs.
	3. Introduce bpstat_free
	4. Change bpstat->breakpoint_at to point at bp_location.
	5. Move the 'cond' field from breakpoint to bp_location.
	6. Extract some code into separate functions
	7. Handle pending breakpoints in breakpoint_re_set_one
	8. Allow breakpoint to have multiple locations.
	9. Create multiple locations for breakpoints in constructors
	and template functions

Patches 1-3 are rather trivial, and already committed. The remaining patches
were already reviewed by Jim Blandy, and revised, and re-reviewed 
several times, and are actually all approved now. However, breakpoint.c is 
scary, and the patches are big, so I'll appreciate all possible review. If I 
don't get any objections within 2 weeks, I'm gonna commit those patches as is.

- Volodya


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