Re: Toward multicore GDB - Set theory

[Tom Tromey <tromey@redhat.com>]

>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:

Stan> We then use set notation interesting with commands:

Stan> (gdb) [.7-80] print mytlsglob
Stan> $45 = [.8,16,32,64] 0xbadbad ; [.*] 0xfeedface

Stan> shows most threads with the same value for a variable, and a handful
Stan> of threads with a different value.

This is a tricky example since it implies pushing a lot of smarts into
'print'.  I'm in favor of it, I think it is the only way for this to
make sense and scale -- just painful.

Stan> Similarly, the single-thread option for breakpoints will be
Stan> generalized to sets.

Yes, nice.  I have actually been considering doing this myself, as a
follow-on to the ambiguous linespec patch.

Stan> The astute reader will notice many holes.  In particular, I am not
Stan> giving a formal definition of set syntax and how it fits into the CLI,
Stan> because I want us to develop some consensus on what would work best.
Stan> Key decisions to be made are:

Stan> 1) square brackets? curly brackets? nothing at all?
Stan> 2) prefix? postfix? both?
Stan> 3) build in extensibility? or leave to Python somehow?
Stan> 4) is there a better term than ptc set?

I think in the past we talked about square brackets and prefix.
How about we consider that as a straw proposal?

(gdb) [0-13] print x

I think that would suffice for all commands, even breakpoints; though it
may be slightly confusing that breakpoints "capture" the set while other
commands operate on them immediately.  If that is too confusing then
breakpoints could do another syntax, eg:

(gdb) break [0-13] function         # "semi-prefix"
(gdb) break function thread [0-13]  # "natural extension"


Allowing the definition of new kinds of ptc keywords from Python seems
natural.  I guess the question is whether it would be performant enough.

I think it would make sense to hold off on that, but carefully define
the PTC set syntax to be extensible and write the code to conservatively
reject unrecognized constructs.  Then we have leeway to make additions
in the future.

Tom