Re: [PATCH 2/3] skip_prolgoue (amd64)

[Pedro Alves <palves@redhat.com>]

On 12/04/2013 05:54 PM, Doug Evans wrote:
> 
> The dcache and non-stop are basically incompatible, but we need both.
> With any other thread still running the ground can be pulled out from
> underneath my view of memory from a stopped thread (even when I'm in
> the middle of viewing it - I can imagine a pretty-printer of a complex
> object getting really confused for example).

Right.  My view is that for a single quick operation, it's fine
to rely on the cache.  E.g., a backtrace, or printing a variable
while other threads are running.  GDB can give you skewed results
here with or without the cache.  Between single higher level operations
though, a lot of time could pass between two backtraces, and
the likeliness of the cache getting stale increases.  This
suggests investigating the idea of having the cache have a
time based lifetime, in addition.  Though I suspect that's a
lot of more complexity, for diminishing returns.  It's nice
that the second backtrace is faster than the first, but it's
really time of the first backtrace that we should be
optimizing for, IMO.

> It feels like there's diminishing returns and increasing costs the
> farther we go to try to protect the user from this.

Exactly.

Related, I've considered before that some memory accesses may
need to be atomic with the inferior (e.g., things like reading
dynamic linker structures), and that GDB core will need to know
to stop the target, batch a few reads, and re-resume the target.
And that that could also be extended to a user
knob -- "set want-to-be-sure-values-I'm-reading-aren't-skewed-by-running-threads-so-please-pause-them-for-me-as-needed on/off".
Possibly with a shorter spelling.  :-)

-- 
Pedro Alves