Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>,
	       "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: palves@redhat.com, jan.kratochvil@redhat.com, gdb-patches@sourceware.org
Subject: Re: [rfc] btrace: control memory access during replay
Date: Wed, 14 May 2014 15:35:00 -0000	[thread overview]
Message-ID: <53738D3E.60606@redhat.com> (raw)
In-Reply-To: <8338hta0hm.fsf@gnu.org>

On 04/04/2014 10:48 AM, Eli Zaretskii wrote:
>> From: "Metzger, Markus T" <markus.t.metzger@intel.com>
>> CC: "palves@redhat.com" <palves@redhat.com>, "jan.kratochvil@redhat.com"
>> 	<jan.kratochvil@redhat.com>, "gdb-patches@sourceware.org"
>> 	<gdb-patches@sourceware.org>
>> Date: Fri, 4 Apr 2014 09:42:46 +0000
>>
>>> Other than that, the documentation parts are approved.  However, I
>>> wonder whether "allow-memory-access" is a good name for a setting
>>> which actually allows access to writable portion of the memory.  IOW,
>>> even when the value is OFF, we do allow access to memory, just not the
>>> writable portion of it.
>>
>> Agreed; allow-access-to-writable-memory-while-replaying is a bit long, though.
> 
> How about access-writable-memory?

Sounds fine to me.

What's the likelihood of another variant appearing?  That is,
I'm mildly wondering if it should be an enum from the get go:

 set record btrace replay-memory-access read-only|read-write|...|...

I also got a little confused with:

"The accessed memory corresponds to the end of the recorded
execution trace."

Maybe we should say "live program" instead ?

Also, I think it'd be good to add an into to the manual explaining
the use case.  Something like:

The btrace record target does not trace data.  As a convenience,
when replaying, GDB reads read-only memory off the live program
directly, assuming that the addresses of the read-only areas
don't change.  This for example makes it possible to disassemble
code while replaying, but not to print variables.
In some cases, being able to inspect variables might be useful.
You can use the following command for that:

and then followed by the docu for the command like you had:

+@kindex set record btrace
+@item set record btrace allow-memory-access
+Control the behavior of the @code{btrace} recording method when
+accessing memory during replay.  If ON, @value{GDBN} will allow
+arbitrary memory accesses.  The accessed memory corresponds to the end
+of the recorded execution trace.  It does not necessarily correspond
+to the current replay position.  If OFF (the default), @value{GDBN}
+will only allow accesses to read-only memory.
...

I actually didn't see anything in the patch that actually makes the
setting work.

Also, please install a show hook in the command, so that i18n
can work.

Thanks,
-- 
Pedro Alves


  reply	other threads:[~2014-05-14 15:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-04  8:56 Markus Metzger
2014-04-04  9:16 ` Eli Zaretskii
2014-04-04  9:44   ` Metzger, Markus T
2014-04-04  9:48     ` Eli Zaretskii
2014-05-14 15:35       ` Pedro Alves [this message]
2014-05-19  7:51         ` Metzger, Markus T
2014-05-19 17:44           ` Pedro Alves
2014-05-20  7:01             ` Metzger, Markus T

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=53738D3E.60606@redhat.com \
    --to=palves@redhat.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=markus.t.metzger@intel.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