From: Keith Seitz <keiths@redhat.com>
To: archer@sourceware.org
Subject: Explicit Linespecs Branch Created
Date: Mon, 11 Jun 2012 20:27:00 -0000 [thread overview]
Message-ID: <4FD6548D.3050701@redhat.com> (raw)
Hi,
For the past few weeks, I've been working on a little project to
implement what I've been calling "explicit linespecs." These are
linespecs that bypass the linespec parser altogether. [Example: "break
-function main -label foo -offset 3"]
This feature has been requested a few times, most notably as mi/13139.
A consequence of this patch series is also that all linespecs (on
supported breakpoint types) are now converted to this explicit form. The
addr_string is basically used for display purposes only.
Since this patchset is so large and invasive, I have checked it into the
Archer repository for "pre-review." It's in the
archer-keiths-explicit-linespecs branch. I would especially appreciate
feedback on:
- Syntax of the CLI and MI breakpoint commands.
+ MI: -break-insert -c 'foo == bar' -t -e -s source.c -f function -l
label -o offset
Currently, the explicit linespec flag (-e) must be the last option in
the command. Everything after "-e" is restricted to explicit linespecs.
[This restriction was enabled so that we don't have to require some
really ugly quoting, e.g., -break-insert -e "-f main -offset 3" -c "foo
== bar".
+ CLI: break -source source.c -function function -label label -offset
offset -condition "foo == bar" -thread 1
The various flags may be abbreviated, "-func" or "-f" is acceptable.
["thread" takes precedence over "task"]
When setting an explicit linespec, users may not use the keywords "if",
"thread", or "task". If using explicit linespecs, *everything* must be
explicitly specified.
- New error messages
+ I have introduced several new error messages. They should be
double-checked:
o "invalid linespec argument, \"%s\"" : This is output when the
user attempts to use an invalid explicit linespec flag, e.g., "-foobar".
o "missing argument for \"%s\" : This is output when the user omits
an argument for a given explicit linespec flag.
When these syntaxes are finalized, I will commit new documentation for
them to the branch. [As usual, it's the last task on my TODO list. If I
would stop finding bugs, I could probably get around to this sooner than
later.]
This patchset is not ready for prime time (certainly not until after 7.5
branches). I'm still dreaming up test cases, finding new bugs (e.g.,
"cond" doesn't play nicely with this yet) and tweaking this and that,
but AFAIK, it causes no regressions in the test suite.
Any feedback appreciated,
Keith
next reply other threads:[~2012-06-11 20:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 20:27 Keith Seitz [this message]
2012-06-15 18:32 ` Tom Tromey
2012-06-21 19:09 ` Keith Seitz
2012-06-21 20:38 ` Tom Tromey
2012-06-29 13:31 ` 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=4FD6548D.3050701@redhat.com \
--to=keiths@redhat.com \
--cc=archer@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).