This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/7 V2] Trust readonly sections if target has memory protection
- From: Doug Evans <dje at google dot com>
- To: Pedro Alves <palves at redhat 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: Tue, 8 Oct 2013 19:24:18 -0700
- Subject: Re: [PATCH 0/7 V2] Trust readonly sections if target has memory protection
- Authentication-results: sourceware.org; auth=none
- References: <1378432920-7731-1-git-send-email-yao at codesourcery dot com> <1378641807-24256-1-git-send-email-yao at codesourcery dot com> <201309091916 dot r89JGbpf009986 at glazunov dot sibelius dot xs4all dot nl> <522E9A8A dot 7040509 at codesourcery dot com> <52317B66 dot 3020602 at codesourcery dot com> <201309120949 dot r8C9nFsJ016506 at glazunov dot sibelius dot xs4all dot nl> <5232C9EC dot 2040707 at codesourcery dot com> <5249B9F9 dot 4030901 at redhat dot com>
On Mon, Sep 30, 2013 at 10:50 AM, Pedro Alves <palves@redhat.com> wrote:
> [...]
> We have similar infrastructure already, in dcache.c -- we use
> it for stack memory nowadays, and if the memory region is marked as
> cacheable. We used to support caching more than just stack, but
> that was never enabled by default because it may not be safe to
> read memory outside of the range the caller is specifying, because of
> things like memory mapped registers, etc. (In the case of stack, we assume
> stack is allocated in page chunks, so that dcache never steps on memory is
> should not). But in cases like disassembly, we're being driven by debug
> info or user input. As GDB knows upfront the whole range of memory it'll
> be fetching, accessing a bigger chunk upfront, as long as it doesn't
> step out of the range we read piecemeal anyway, should have no effect
> on correctness.
For reference sake,
ISTR prologue parsing being another place where we saw pain (not
often, but painful when it happens).
We also saw paradoxical slowdowns from using trust-readonly.
The culprit was target_section_by_addr.
Should be fixable of course, but heads up.