RE: [rfc] btrace: control memory access during replay

["Metzger, Markus T" <markus.t.metzger@intel.com>]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Pedro Alves
> Sent: Wednesday, May 14, 2014 5:35 PM


> On 04/04/2014 10:48 AM, Eli Zaretskii wrote:

> >>> 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 don't see another variant right now but I also don't see why it
shouldn't be an enum.


> 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 ?

Would "live program" still be OK for core files?


> 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:

Will do.


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

The patch is using an existing variable to guard writable memory
access.  We already allow write-access for breakpoints during
replay.  This patch is now adding a CLI for the guard variable.


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

I'm using the default set/show functions with _("") descriptions
for both set and show.  Isn't that enough for i18n?

In case it isn't, would I need a set function, as well?

Thanks,
Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052