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] Disassembly improvements


On 10/11/2013 10:34 PM, Doug Evans wrote:

> This is a specific fix to a general problem.

I don't know that this is a general problem.  It may look like one,
but it's not super clear to me.  Yes, we might have a similar problem
caused by lots of tiny reads from the target during prologue analysis.
But the approach there might be different from the right approach for
disassembly, or we could also come to the conclusion the problem
there is not exactly the same.

> Question: How much more of the general problem can we fix without
> having a fix baked into the disassembler?

The disassembly use case is one where GDB is being
told by the user "treat this range of addresses that I'll be
reading sequencially, as code".  If that happens to trip on some
memory mapped registers or some such, then it's garbage-in,
garbage-out, it was the user's fault.

As I mentioned in <https://sourceware.org/ml/gdb-patches/2013-09/msg01013.html>,
I'd rather we analyze the use cases independently (I'm not saying
they're not the same).

If we find commonalities, we can certainly factor things out and
come up with more general abstractions then.

If I were to try one, I think it would be along the lines of
a new TARGET_OBJECT_DISASM_MEMORY, and somehow pass more info down
the target_xfer interface so that the the core memory reading code
handles the caching.  Probably, that'd be done with a new pair of
'begin/end code caching' functions that would be called at the
appropriate places.  The new code in dis_asm_read_memory would
then be pushed to target.c, close to where stack cache is handled.

The main point there should be consensus on, is that a caching
scheme is a better solution for the disassembly use case, than trusting
read only sessions is, for the later doesn't have the problem with
self-modifying code, and, in addition, it also speeds up disassembling
when there is _no_ corresponding binary/'text section'.

I don't think there's any need to hold considering this quite
localized fix for slow disassembling as is while we investigate
other use cases.  IOW, we should let the code start small, and
grow/evolve from there.

-- 
Pedro Alves


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