Tom Tromey
Sat Sep 11 01:46:00 GMT 2010

>>>>> "Stan" == Stan Shebs <> writes:

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

Yeah.  More or less I am working through rediscovering the reasons all
those things were in the spec in the first place.

>From the global breakpoint message, it looks like you are planning to
tackle this in some way.  I forgot about this part of your project,
sorry about that.

Tom> This means associating new metadata with a new kind of breakpoint and
Tom> coming up with a new command name.  This seems like more work, for a
Tom> result that is not as nice to use.

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

My initial patch was to replace the pspace field in breakpoint with an
I/T set.  This works fine, the problem is that it breaks the MI
invariant of one source location per breakpoint.  I think your approach
probably won't have this problem, because (I assume) your global
breakpoints are inherently objfile-specific.

What kinds of specifications does the kernel module accept?
If the kernel accepts something more limited than gdb, we could always
just upload an approximation to an I/T set and let gdb filter out the
ones it doesn't care about.

FWIW, my current use case is very simple: start gdb on gcc, set a
breakpoint that will be resolved in cc1, run.  I think this is a pretty
reasonable thing to want to do; for me it seems ok to require a little
extra work (like adding "[*]" to the break command), but not a lot of
extra work (like looking up the full path to cc1 to give to

Maybe it would be ok for "break collect_args" to mean "break on the
first instance of collect_args that is resolved anywhere, but now
convert this to a breakpoint that only resolves to this particular
function in this objfile.  I don't know... it doesn't feel completely
natural to me, but that isn't a very strong reason for anybody else to
do anything :)

Stan> I/T sets are one of the bits that didn't make it from
Stan> multiprocess-20081120-branch to the trunk.

I did look at this, but I ended up writing my own.  You can see it here:;a=blob_plain;f=gdb/itset.h;hb=archer-tromey-multi-inferior;a=blob_plain;f=gdb/itset.c;hb=archer-tromey-multi-inferior

Stan> In my global breakpoint project
Stan> ( ), I've been
Stan> using a "process" keyword where "thread" and "task" are used now.

My first reaction to these kinds of extensions is caution, because they
can introduce expression ambiguity.  (I've sometimes considered adding
";" as an expression terminator to help with this...)

Could you expand more on what you are planning?  E.g., exactly what
syntax you intend to support, how users will specify sets of processes,
etc?  I read your post and I see the PID range thing... is that the only
way?  That isn't ambiguous, but putting an I/T set here would be.
Unless we changed the I/T set syntax (using {} would work).

I guess I don't mind if we have multiple syntaxes, though it seems like
if the I/T set syntax is flexible enough and simple enough, we could
just use it everywhere.

Maybe I should just wait until you and/or the UPC guys have everything
finished :-).  It sounds like we have substantial overlap.  There's also
a lot of overlap between your work and the ugdb project... we'll have
some interesting discussions at the GCC Summit this year :-)


More information about the Gdb mailing list