Stan Shebs
Fri Sep 10 23:07:00 GMT 2010

Tom Tromey wrote:
> Another use case would be putting a breakpoint on a particular function,
> say from some kind of symbol view.  After some reflection, I think the
> solution in this case lies in a linespec extension, not in I/T sets.  In
> particular:
>   break [*]

The '#' syntax is in the old spec actually, you even commented about it 
in :-)

> I also looked into another idea we discussed -- having a kind of
> meta-breakpoint for I/T sets that sets new concrete breakpoints when the
> appropriate events occur.
> This means associating new metadata with a new kind of breakpoint and
> coming up with a new command name.  This seems like more work, for a
> result that is not as nice to use.

What I've been doing for now for global breakpoints is to add the 
quasi-i/t set as another attribute of a breakpoint, a la thread or 
cond_string.  This then is both interpreted by GDB, for processes that 
are currently under GDB's control, and passed to a kernel module that is 
monitoring all other processes for hits.


More information about the Gdb mailing list