Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> I'm very sorry for the delay in responding to this.

It is no problem, and thanks for replying.

Tom> Right now there are several patches (and planned patches) to make
Tom> debuginfo reading lazier: my lazy reading patch for new inferiors,

Pedro> I never replied to your patch, but my reaction was that it is
Pedro> probably breaking breakpoints in the new inferiors today, even
Pedro> without any linespec/multi breakpoints work.

Is there a way to set a breakpoint in a new inferior without first
loading the debuginfo by hand?  It has been a while since I was looking
at this, but I don't remember finding a way.

If there is one, though, I can easily test this.

Pedro> Wouldn't e.g., making debug info reading smarter (the sharing of
Pedro> objfiles between inferiors work/idea?) mostly dispense that
Pedro> approach?

That would help for much of the debuginfo, but not all of it.  I think
it would depend on how much sharing there is across inferiors in a given
session.

FWIW I have taken a couple stabs at making objfile sharing work.  It is
a lot harder than I thought it would be, and it winds up requiring
conditions which I am not confident are always true.

The big problem comes from symbols.  In the new setup, symbols are
independent of the program space.  SYMBOL_VALUE_ADDRESS still needs the
program space, though -- so we add a mapping from objfile to the
per-program-space objfile wrapper.  But, to actually use this map, the
current program space must be set properly at any use of
SYMBOL_VALUE_ADDRESS.  It isn't clear to me that this is guaranteed.  I
think there are other cases like this too.

Pedro> It's not just user breakpoints that worry me with simply avoiding
Pedro> debug info altogether with some per-inferior flag, rather than
Pedro> making it depeng on need/request.
[...]

Thanks, this is very helpful info.

Pedro> I'm not sold on this either.  One could do something similar,
Pedro> but leavy the default the way around -- have a new "final"
Pedro> property/option of breakpoints --- once it's spec resolves,
Pedro> it no longer gets locations auto-added, and have the user
Pedro> request for final'ness explicitly.  The "final" property
Pedro> does not need to be final itself, it could be toggleable.

Ok.  I will implement it the "full" way first; if we find it isn't so
good in practice we can always change it or add an option later on.

Pedro> What I don't think I have seen addressed is how the proposal
Pedro> interacts with multi-exec.  E.g, suppose I have program foo
Pedro> loaded once (one inferior) and program bar loaded twice (two
Pedro> inferiors).  I have one of the bar inferiors in focus, 
Pedro> and I do "b main".  How many locations does this resolve to?
Pedro> One, two, or three?  Currently, it resolves to two.

Three, following the rule that a breakpoint will fire at all matching
locations.

Tom