From: Tom Tromey <tromey@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Jerome Guitton <guitton@adacore.com>,
Jan Kratochvil <jan.kratochvil@redhat.com>,
gdb-patches@sourceware.org
Subject: Re: RFA: implement ambiguous linespec proposal
Date: Wed, 09 Nov 2011 17:12:00 -0000 [thread overview]
Message-ID: <m3r51hfcfx.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20111109160529.GO14508@adacore.com> (Joel Brobecker's message of "Wed, 9 Nov 2011 08:05:29 -0800")
>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
Joel> We have a similar issue: When the user inserts a breakpoint, and there
Joel> are multiple possible choices, we have two scnearios:
Joel> 1. He selects `all' -> In that case, we actually create one breakpoint
Joel> with multiple locations;
Joel> 2. He selects a subset -> In that situation, we create one breakpoint
Joel> per location.
Joel> I think this can be pretty confusing.
This happens with the new code too, though it depends on the
'multiple-symbols' setting. For 'all', there is no menu, just a
breakpoint with all the locations.
The code is based around the idea that a linespec has a canonical form.
Re-setting is done based by re-parsing the original linespec (though
there are exceptions to this rule -- linespec is pretty complicated);
but filtering is done based on the canonical form.
The exception to the re-parsing rule is for linespecs where the original
text is context-relative. For example, "break 57" -- it would not make
sense to try to re-parse "57", instead linespec returns a form of
"file.c:57".
So, I misspoke a little upthread. The problem with the searching
namespace using declarations for C++ is that the linespec is
context-relative, but there is no unique non-relative form we can
rewrite. That is, in the example, the rewritten form for re-parsing
would have to be both "N1::m" and "N2::m".
Joel> [1]: We tried contributing it, but it was too hacky to really be part
Joel> of the FSF sources. The main complaint at the time was the fact
Joel> that it introduced a canonical form that was specific to Ada. I was
Joel> planning on looking at generalizing it to all languages, but never
Joel> got around to doing it.
Do you have a URL? This would be a good time to resurrect it.
I would like to take a look... I don't know Ada, though, so I'm going to
guess that I probably won't be able to fix it up.
In terms of the proposed patch, the key question is whether rewriting is
needed for Ada, and if so, whether it can be done uniquely. Or, if
using the simple name is always enough... in this case the solution is
very easy.
Tom
next prev parent reply other threads:[~2011-11-09 17:12 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-28 17:34 Tom Tromey
2011-10-28 20:52 ` Matt Rice
2011-11-01 20:38 ` Tom Tromey
2011-10-28 22:41 ` Jan Kratochvil
2011-11-01 20:58 ` Tom Tromey
2011-11-03 20:49 ` Tom Tromey
2011-11-04 7:46 ` Jan Kratochvil
2011-11-08 16:36 ` Tom Tromey
2011-11-09 16:05 ` Joel Brobecker
2011-11-09 17:12 ` Tom Tromey [this message]
2011-11-09 17:56 ` Joel Brobecker
2011-11-09 18:19 ` Tom Tromey
2011-11-09 19:00 ` Joel Brobecker
2011-11-14 21:04 ` Tom Tromey
2011-11-14 21:32 ` Jerome Guitton
2011-11-09 18:37 ` Tom Tromey
2011-11-14 21:11 ` Tom Tromey
2011-11-15 16:30 ` Tom Tromey
2011-11-15 16:59 ` Pierre Muller
2011-11-16 0:09 ` Jan Kratochvil
2011-11-16 1:58 ` Joel Brobecker
2011-11-16 14:46 ` Tom Tromey
2011-11-18 14:10 ` Tom Tromey
2011-11-16 21:23 ` Stan Shebs
2011-11-16 2:28 ` Yao Qi
2011-11-16 3:20 ` Doug Evans
2011-11-16 14:46 ` Tom Tromey
2011-11-16 16:06 ` Tom Tromey
2011-11-16 4:57 ` Doug Evans
2011-11-16 5:22 ` Doug Evans
2011-11-16 14:54 ` Tom Tromey
2011-11-16 16:32 ` Doug Evans
2011-11-16 16:39 ` Tom Tromey
2011-11-16 14:49 ` Tom Tromey
2011-11-16 8:15 ` Yao Qi
2011-11-16 16:17 ` Tom Tromey
2011-11-16 15:43 ` Yao Qi
2011-11-16 16:11 ` Tom Tromey
2011-11-16 16:44 ` Tom Tromey
2011-11-17 3:49 ` Yao Qi
2011-11-21 21:50 ` Tom Tromey
2011-11-23 21:33 ` Tom Tromey
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=m3r51hfcfx.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=guitton@adacore.com \
--cc=jan.kratochvil@redhat.com \
/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