This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/3] skip_prolgoue (amd64)
- From: Pedro Alves <palves at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: Yao Qi <yao at codesourcery dot com>, Mark Kettenis <mark dot kettenis at xs4all dot nl>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Thu, 05 Dec 2013 11:47:38 +0000
- Subject: Re: [PATCH 2/3] skip_prolgoue (amd64)
- Authentication-results: sourceware.org; auth=none
- References: <1385735051-27558-1-git-send-email-yao at codesourcery dot com> <1385735051-27558-3-git-send-email-yao at codesourcery dot com> <201311291436 dot rATEaZ5Z030292 at glazunov dot sibelius dot xs4all dot nl> <201311291605 dot rATG5XVb030184 at glazunov dot sibelius dot xs4all dot nl> <52994E79 dot 4000004 at codesourcery dot com> <5299B9D0 dot 2020304 at redhat dot com> <CADPb22REFRk5r5sb_TmfduDEbos4sooF6LP9GKq9fXQ+g0T6GQ at mail dot gmail dot 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