From: "Metzger, Markus T" <markus.t.metzger@intel.com>
To: Pedro Alves <palves@redhat.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Simon Marchi <simon.marchi@ericsson.com>
Subject: RE: [PATCH v2 2/2] btrace: allow recording to be started for running threads
Date: Wed, 25 Jan 2017 15:53:00 -0000 [thread overview]
Message-ID: <A78C989F6D9628469189715575E55B2340044AFA@IRSMSX104.ger.corp.intel.com> (raw)
In-Reply-To: <e7a77d2d-b15f-152e-bbc2-81296b6ef101@redhat.com>
Hello Pedro,
Thanks for your review.
> > +/* Validate that we can read PTID's registers. */
> > +
> > +static void
> > +validate_registers_access_ptid (ptid_t ptid)
> > +{
> > + struct cleanup *cleanup = save_inferior_ptid ();
> > +
> > + inferior_ptid = ptid;
> > + validate_registers_access ();
> > + do_cleanups (cleanup);
> > +}
>
> Do we need this, we we have the new function added
> by patch #1 ?
This is a safeguard. I don't expect that we will ever throw, here.
> > + && can_access_registers_ptid (tp->ptid))
>
> If you have this check, why do you need to the TRY/CATCH ?
>
> Or even, given the validate_registers_access_ptid check
> above, why is this check necessary?
>
> > + btrace_add_pc (tp);
> > + }
> > + CATCH (exception, RETURN_MASK_ALL)
>
> Adding a RETURN_MASK_ALL always raises alarm bells,
> because this swallows a user-typed ctrl-c, which
> is probably wrong.
>
> > + {
> > + btrace_disable (tp);
> > + }
> > + END_CATCH
The TRY/CATCH is to clean things up in case of errors or ctrl-c. The caller
will clean things up for previously enabled threads but expects each
btrace_enable to either succeed or fail and throw.
I see that I forgot to rethrow, though. This is not intended to swallow
the error - only to disable tracing again in case of errors.
The can_access_registers_ptid check is to avoid the error and thus allow
"record btrace" for running (or exited) threads where the btrace_add_pc
call can be omitted.
> > +# We need to enable non-stop mode for the remote case.
> > +gdb_test_no_output "set non-stop on"
>
> This is too late with --target_board=native-extended-gdbserver.
> Use instead:
>
> save_vars { GDBFLAGS } {
> append GDBFLAGS " -ex \"set non-stop on\""
> clean_restart $testfile
> }
This test seems to run fine with --target_board=native-extended-gdbserver.
Making the change nevertheless. There's another instance of this in
gdb.btrace/non-stop.exp. Will fix this in a separate patch.
A different test, gdb.btrace/enable.exp is failing with that target_board.
Thanks,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2017-01-25 15:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-20 14:39 [PATCH v2 0/2] thread, btrace: allow "record btrace" " Markus Metzger
2017-01-20 14:39 ` [PATCH v2 2/2] btrace: allow recording to be started " Markus Metzger
2017-01-25 14:32 ` Pedro Alves
2017-01-25 14:36 ` Pedro Alves
2017-01-25 15:53 ` Metzger, Markus T [this message]
2017-01-25 16:13 ` Pedro Alves
2017-01-26 14:54 ` Metzger, Markus T
2017-01-20 14:39 ` [PATCH v2 1/2] thread: add can_access_registers_ptid Markus Metzger
2017-01-25 14:33 ` Pedro Alves
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=A78C989F6D9628469189715575E55B2340044AFA@IRSMSX104.ger.corp.intel.com \
--to=markus.t.metzger@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=simon.marchi@ericsson.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