This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Delegate to target_ops->beneath to read cache lines

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 &current_target.  I may mess up
something then.

> Note that using &current_target in dcache_read_line will cause an
> endless recursion, so I change it to current_target.beneath.  IMO,
> other &current_target usages should be changed to
> current_target.beneath too.

I'll get rid of it from commit log.

Yao (éå)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]