This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v9 21/29] record-btrace: provide xfer_partial target method
- From: Pedro Alves <palves at redhat dot com>
- To: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- Cc: "jan dot kratochvil at redhat dot com" <jan dot kratochvil at redhat dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 20 Dec 2013 15:55:58 +0000
- Subject: Re: [PATCH v9 21/29] record-btrace: provide xfer_partial target method
- Authentication-results: sourceware.org; auth=none
- References: <1387471499-29444-1-git-send-email-markus dot t dot metzger at intel dot com> <1387471499-29444-22-git-send-email-markus dot t dot metzger at intel dot com> <52B34555 dot 8040200 at redhat dot com> <A78C989F6D9628469189715575E55B230AA3B9AE at IRSMSX104 dot ger dot corp dot intel dot com> <A78C989F6D9628469189715575E55B230AA3B9DE at IRSMSX104 dot ger dot corp dot intel dot com>
On 12/20/2013 01:54 PM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: Metzger, Markus T
>> Sent: Friday, December 20, 2013 2:37 PM
>> To: Pedro Alves
>
>
>> I can try to make raw_memorx_xfer_partial return on
>> TARGET_XFER_E_UNAVAILABLE. This will be more intrusive, though.
>
> I did not get any regressions on 64bit IA Linux native.
> And the error message is definitely nicer.
Can you show the patchlet you did, and the before/after gdb
output though? I'd be better to see that, and have any possible
follow up discussion discussion here now, rather than fractured
to a potential repost of the series.
BTW, I think that ...
+ /* Filter out requests that don't make sense during replay. */
+ if (!record_btrace_allow_memory_access && record_btrace_is_replaying ())
+ {
+ switch (object)
+ {
+ case TARGET_OBJECT_MEMORY:
+ case TARGET_OBJECT_RAW_MEMORY:
+ case TARGET_OBJECT_STACK_MEMORY:
+ {
+ struct target_section *section;
+
+ /* We do not allow writing memory in general. */
+ if (writebuf != NULL)
+ throw_error (NOT_AVAILABLE_ERROR,
+ _("This record target does not record memory."));
+
+ /* We allow reading readonly memory. */
+ section = target_section_by_addr (ops, offset);
+ if (section != NULL)
+ {
+ /* Check if the section we found is readonly. */
+ if ((bfd_get_section_flags (section->the_bfd_section->owner,
+ section->the_bfd_section)
+ & SEC_READONLY) != 0)
+ {
+ /* Truncate the request to fit into this section. */
+ len = min (len, section->endaddr - offset);
+ break;
... here, this should return TARGET_XFER_E_IO rather than break and
falling through to the code that defers to the target beneath, as the
caller will already do that for memory transfers.
+ }
+ }
+
+ throw_error (NOT_AVAILABLE_ERROR,
+ _("This record target does not record memory."));
Then here return TARGET_XFER_E_UNAVAILABLE.
+ }
+ }
+ }
> Should we add a new '-3' return value to be on the safe side?
> I.e. raw_memory_xfer_partial would bail out on -3 and keep
> going for -1 and -2.
I'm not seeing why we'd need that. TARGET_XFER_E_UNAVAILABLE
is exactly designed for this use case. It's just that
it was added recently, and we hadn't found a use outside
tracing yet.
--
Pedro Alves