This is the mail archive of the gdb-patches@sourceware.org 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 0/7 V2] Trust readonly sections if target has memory protection


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 (éå)


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