This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] btrace: control memory access during replay
- From: Pedro Alves <palves at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>, "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- Cc: palves at redhat dot com, jan dot kratochvil at redhat dot com, gdb-patches at sourceware dot org
- Date: Wed, 14 May 2014 16:35:26 +0100
- Subject: Re: [rfc] btrace: control memory access during replay
- Authentication-results: sourceware.org; auth=none
- References: <1396601781-25010-1-git-send-email-markus dot t dot metzger at intel dot com> <8361mpa1z9 dot fsf at gnu dot org> <A78C989F6D9628469189715575E55B230C148832 at IRSMSX104 dot ger dot corp dot intel dot com> <8338hta0hm dot fsf at gnu dot 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