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: Yao Qi <yao at codesourcery dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Mark Kettenis <mark dot kettenis at xs4all dot nl>, <gdb-patches at sourceware dot org>
- Date: Tue, 15 Oct 2013 08:42:58 +0800
- 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 10/01/2013 01:50 AM, Pedro Alves wrote:
I've been background-thinking about taking a step back and understand
why each use case that is sped up with this patch is slow to begin with.
That is, the series jumps to a solution, but we haven't done our due diligence
with analyzing the problem thoroughly, IMO. E.g., for the disassembly use
Due diligence was done, but in a different way :). Option
"trust-readonly-sections" was mentioned to improve the performance of
remote debugging and "turning it on in default" was discussed when this
option was added. We didn't turn it on in default because of bad code
on non-memory protection systems. V1 follows this idea to let GDB to
know which targets are memory protection systems.
case, presented in the v1 series, I'd think that the problem is that GDB is
fetching data off the target instruction by instruction, instead of requesting
a block of memory and working with that. More aggressive over fetching
could be a better/safer approach.
I agree.
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.
We have to improve dcache.c at first. Nowadays, dcache requests one
cache line from the target in one time, regardless the actual size of
memory requested.
--
Yao (éå)