This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Delegate to target_ops->beneath to read cache lines
- From: Yao Qi <yao at codesourcery dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Fri, 29 Nov 2013 21:28:08 +0800
- Subject: Re: [PATCH] Delegate to target_ops->beneath to read cache lines
- Authentication-results: sourceware.org; auth=none
- References: <1385554824-7159-1-git-send-email-yao at codesourcery dot com> <5295F877 dot 3060004 at redhat dot com> <52980180 dot 1050000 at codesourcery dot com> <529883D7 dot 3030606 at redhat dot com>
On 11/29/2013 08:08 PM, Pedro Alves wrote:
> Hmm, that's not what I recall and documented in
> target_read_memory, etc.
>
> /* Dispatch to the topmost target, not the flattened current_target.
> Memory accesses check target->to_has_(all_)memory, and the
> flattened target doesn't inherit those. */
>
> And indeed, if I tweak the patch to drop that hunk,
> that's still what I see. What recursion did you see?
I can see a segmentation fault instead of a endless recursion today :-/
(top-gdb) n
1420 if (ops->to_has_all_memory (ops))
(top-gdb) p ops->to_has_all_memory
$13 = (int (*)(struct target_ops *)) 0x0
(top-gdb) p current_target.to_has_all_memory
$14 = (int (*)(struct target_ops *)) 0x0
The quoted documentation correctly explainss the behaviour here.
The endless recursion I saw yesterday is that both current_target.to_xfer_partial
and current_target.beneath->to_xfer_partial are core_xfer_partial. Looks
like it delegates to "itself", and causes an endless recursion, so I use
current_target.beneath instead of ¤t_target. I may mess up
something then.
> Note that using ¤t_target in dcache_read_line will cause an
> endless recursion, so I change it to current_target.beneath. IMO,
> other ¤t_target usages should be changed to
> current_target.beneath too.
I'll get rid of it from commit log.
--
Yao (éå)