From: Doug Evans <xdje42@gmail.com>
To: Keith Seitz <keiths@redhat.com>
Cc: "gdb-patches\@sourceware.org ml" <gdb-patches@sourceware.org>
Subject: Re: [RFA 0/9] Explicit locations v2 - Introduction
Date: Sun, 12 Oct 2014 19:50:00 -0000 [thread overview]
Message-ID: <m3y4slm5kf.fsf@sspiff.org> (raw)
In-Reply-To: <536BC52D.80800@redhat.com> (Keith Seitz's message of "Thu, 08 May 2014 10:55:57 -0700")
Keith Seitz <keiths@redhat.com> writes:
> Hi,
>
> I would like to resurrect this project from last year.
>
> This patch series introduces "explicit" locations, which allow users
> to explicitly specify location attributes when setting
> breakpoints. This feature can be especially handy, for example, when
> an application defines multiple functions of the same name:
>
> (gdb) break -source file1.c -function multiple_symbols_with_this_name
>
> In this case, gdb will only attempt to set a breakpoint in the given
> source file. If the given symbol is not defined in the file, gdb will
> do the usual pending breakpoint query.
>
> This revision is largely the same as the one I posted last year with
> one notable change: I have implemented probe locations.
>
> Consequently, this API change now supports the following "event
> locations": linespec, address (formerly "*EXPR"), explicit, and probe.
>
> I have attempted to break up the patch to assist review. The intent is
> to apply all patches approved. Nonetheless, each patch may be applied
> sequentially and should not cause any build failures or introduce any
> test suite regressions.
>
> I have tested each patch on both x86_64 native and native-gdbserver.
Hi.
I've read the patch set twice more now, including reading the patched code.
[That's what weekends are for, right? :-)]
I've got a high level question, and a few nits.
Before I impose submitting another version of the patch I'm hoping
we can get the remaining high level issues resolved first.
I think I better understand the things you have to go through to parse
linespecs, but there's still something here that needs more work.
I think it'll just involve a bit of API tweaking, so nothing major.
I'll leave the discussion to the email with the patch.
Thanks for the effort so far!
Sorry this is taking awhile to review.
prev parent reply other threads:[~2014-10-12 19:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 17:56 Keith Seitz
2014-05-15 17:56 ` Joel Brobecker
2014-05-15 18:09 ` Keith Seitz
2014-05-15 20:03 ` Joel Brobecker
2014-10-12 19:50 ` Doug Evans [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=m3y4slm5kf.fsf@sspiff.org \
--to=xdje42@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=keiths@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