This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] canonical linespec and multiple breakpoints ...
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 02 Aug 2011 11:08:46 -0600
- Subject: Re: [RFC] canonical linespec and multiple breakpoints ...
- References: <20110505162855.GA2546@adacore.com> <m362nmarbv.fsf@fleche.redhat.com> <m3hb68q0no.fsf@fleche.redhat.com> <201108021633.04777.pedro@codesourcery.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