Re: [patch v8 17/24] record-btrace: provide xfer_partial target method

Pedro Alves
2013-12-17T16:56:56Z

On 12/17/2013 11:57 AM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: Pedro Alves [mailto:palves@redhat.com]
>> Sent: Monday, December 16, 2013 8:16 PM
>
>
>>> I changed the return -1 to throw_error (...) and added a check for
>>> writebuf != NULL. Suddenly I got tons of errors when GDB can't insert
>>> breakpoints any longer for (reverse-)stepping.
>>
>> This is why precord keeps track of breakpoints itself too:
> [...]
>>> Also stepping gets broken.
>>
>> I can't immediately why that would be.
>
> Because we can't set temporary breakpoints.
>
>
>>> I now get an error when trying to access a variable with static storage
>>> duration or when trying to access memory directly via its address.
>>> It would be nice to also get an <unavailable> in those cases. This would
>>> require the respective layer to catch my exception.
>>
>> Please try returning TARGET_XFER_E_UNAVAILABLE instead.
>
> That is ignored just like the -1 I returned earlier. I nevertheless changed
> the default return to that since it is more descriptive.

Thanks. Hmm, yes, looks like raw_memory_xfer_partial carries on
looking at the target beneath, and then when that fails, we'll
lose TARGET_XFER_E_UNAVAILABLE, and return TARGET_XFER_E_IO/-1,
losing the better TARGET_XFER_E_UNAVAILABLE.

>>> To avoid those errors when trying to set breakpoints, I could try
>>> providing to_insert_breakpoint and to_remove_breakpoint methods
>>> and maintain my own breakpoints.
>>
>> Right.
>
> I have something to temporarily disable the xfer checks during
> to_insert_breakpoint and to_remove_breakpoint.
>
> Not sure whether this is considered too hacky or what else I'm missing.

It's hacky as the breakpoints in memory will never actually
trigger/execute. If you want to assume that the inferior's current
read only sections match exactly the read only sections the program
had when the trace was taken, I won't insist. The assumption will
fail across tracing e.g., dlopen/dlclose/mmap/unmmap, as breakpoints
will fail to insert on unmapped sections.

> My tests all pass. Any idea where else GDB would need to access
> target memory in order to function correctly?

Can't think of anything.

> Here's the patch. I omit a preparation patch to pass target_ops to
> to_insert_breakpoint and to_remove_breakpoint so that the request
> can be forwarded to the target beneath.
>
> diff --git a/gdb/record-btrace.c b/gdb/record-btrace.c
> index 00a056d..0536071 100644
> --- a/gdb/record-btrace.c
> +++ b/gdb/record-btrace.c
> @@ -42,6 +42,9 @@ static struct target_ops record_btrace_ops;
> /* A new thread observer enabling branch tracing for the new thread. */
> static struct observer *record_btrace_thread_observer;
>
> +/* Temporarily allow memory accesses. */
> +static int record_btrace_allow_memory_access;
> +
> /* Print a record-btrace debug message. Use do ... while (0) to avoid
> ambiguities when used in if statements. */
>
> @@ -805,7 +808,7 @@ record_btrace_xfer_partial (struct target_ops *ops, enum target_object object,
> struct target_ops *t;
>
> /* Filter out requests that don't make sense during replay. */
> - if (record_btrace_is_replaying ())
> + if (record_btrace_allow_memory_access == 0 && record_btrace_is_replaying ())

We use ! for boolean ints, so write:

if (!record_btrace_allow_memory_access && record_btrace_is_replaying ())

--
Pedro Alves