From: Jerome Guitton <guitton@adacore.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
Subject: Re: Symbols/blocks questions
Date: Tue, 22 Sep 2009 09:47:00 -0000 [thread overview]
Message-ID: <20090922094714.GA54075@adacore.com> (raw)
In-Reply-To: <20090919163344.GL7961@adacore.com>
Joel Brobecker (brobecker@adacore.com):
> Jerome Guitton had a serious look at how things are done when
> decoding breakpoint locations, mostly because we wanted Ada and C++
> to use the same code for multiple-location breakpoints. I'll ask him
> to see there is any useful piece of information that might help answer
> these questions.
Not much to add to what Matt already said; and my knowledge in this
area have seriously decreased. I will tell you what I *think* I know.
IIRC, if decode_line_1 returned more than one line, multiple
breakpoints would be created (not a multiple-location
breakpoint). Precisely what happens for overloaded functions: multiple
breakpoints are created. See test ovldbreak.exp.
IIUC, multiple-location breakpoints are only used when the same
"location expression" (addr_string) has to be used to identify a set of
breakpoints; so that, at breakpoint re-set, the same addr_string can
be used to re-create the whole set of sub-breakpoints.
So, I *assume* that if decode_line_1 returns more than one location,
each of these locations has to refer to a different source location;
they should not have the same addr_string. If the same addr_string was
used for such breakpoints, the breakpoint reset would call
decode_line_1 for each of them, find several instances for each of
them, and create duplicates.
Let me give an example from my experience of the problem. In AdaCore's
debugger, we have a feature that allows the user to select a few
choices from the list of all locations that corresponds to a FILE:LINE
expression. Say, if the user set a breakpoint in a generic, the
debugger asks him on which instances breakpoints should be created,
and this user can select several choices in the list. Now, to avoid
having the re-set problem, the debugger has to rewrite the addr_string
to a sort of "canonical" location. If multiple locations are found for
FILE:LINE, say, in Func1 and Func2, then two breakpoints are set in
Func1:FILE:LINE and Func2:FILE:LINE. That's the kind of things that
you have to do when decode_line_1 returns more than 1 location...
prev parent reply other threads:[~2009-09-22 9:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-19 11:52 Vladimir Prus
2009-09-19 14:34 ` Matt Rice
2009-09-19 16:34 ` Joel Brobecker
2009-09-19 16:41 ` Vladimir Prus
2009-09-19 17:02 ` Joel Brobecker
2009-09-19 18:35 ` Vladimir Prus
2009-09-20 15:52 ` Joel Brobecker
2009-09-20 20:30 ` Daniel Jacobowitz
2009-09-22 9:47 ` Jerome Guitton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090922094714.GA54075@adacore.com \
--to=guitton@adacore.com \
--cc=brobecker@adacore.com \
--cc=gdb@sources.redhat.com \
--cc=ghost@cs.msu.su \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox