Re: multi-{inferior,exec}

[Tom Tromey <tromey at redhat dot com>]

Tom> I think the next missing bit is support for I/T sets.

Some updates on this...

Tom> I think we can add an I/T set specifier before the linespec
Tom> argument to "break".  (I couldn't think of other commands that use
Tom> linespecs that would need this...)

It seems to make sense for the other "catch" commands, though those
don't all use linespecs.  Maybe it still makes sense to have the I/T set
as an argument to the command (as opposed to a prefix or a "select"
command), maybe not.  Your comments appreciated.

Tom>     (gdb) break [*] collect_args

Pedro pointed out that this could have an MI problem.  Currently, a
breakpoint is defined as having a single source location (as opposed to
address locations) -- but this kind of breakpoint might have multiple
locations, one per inferior.

I was curious to see what we emit when a breakpoint has multiple
addresses.  Here's the CLI output from a gdb test case:

(gdb) info b
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <MULTIPLE> 
1.1                         y     0x08048447 in foo(int) at ../../../archer/gdb/testsuite/gdb.cp/mb-inline.h:26
1.2                         y     0x080484a7 in foo(int) at ../../../archer/gdb/testsuite/gdb.cp/mb-inline.h:26



Here is the relevant MI:

bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",times="0",original-location="mb-inline.h:26"}

This seems a little weird to me in a couple of ways.

First, addr="<MULTIPLE>" is strange, in that it seems to me that an
attribute would be friendlier.  This text is also undocumented ... but I
presume that in practice MI clients must interpret this?  (I further
suppose the same applies to <PENDING>".)

Second, the various locations are not represented at all.

Third, compare with an ordinary breakpoint:

bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x08048487",func="main()",file="../../../archer/gdb/testsuite/gdb.cp/mb-inline1.cc",fullname="/home/tromey/gnu/archer/archer/gdb/testsuite/gdb.cp/mb-inline1.cc",line="32",times="0",original-location="main"}

Here we get func, file, fullname, and line -- but with a <MULTIPLE>
breakpoint, we do not.


So, since the current situation doesn't seem all that friendly to begin
with, maybe extending it a little for this new use won't be so hard.

Also, it occurred to me that an MI client would have to explicitly
request such a breakpoint with an I/T set -- so maybe it is even ok to
emit something different automatically.


One partly-compatible idea would be to treat each location as a separate
breakpoint, for the purposes of MI output.  (This isn't totally
compatible because some options are per-breakpoint and not
per-location.)

Then, we could provide a new option (and corresponding token in the
-list-features output) to enable "real" output.  The real form would
show all the sub-locations of a master breakpoint.

This approach would also let us fix PR 11657 in a straightforward way.


Pedro and I talked a bit today about some specific use cases.

First, it seems most likely that a front end will typically request a
file:line breakpoint using an absolute path.  That is, the user sees
some source code and clicks on it.

Here, the FE would send the MI equivalent of:

  break [*] file:line

This will do the right thing: break in any inferior reaching that source
line.

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 [*] #libsomething.so#function


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.

Tom