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/18/2013 11:22 AM, Yao Qi wrote:
> On 10/16/2013 08:08 PM, Pedro Alves wrote:
>> Yeah, adding the new target object part is straightforward.  What
>> may not be, is either adjusting the dcache.c to the specifics of
>> disassembly, and range limiting, and making sure the cache is bounded
>> correctly, and flushed at the appropriate times.  It's one of those
>> "must try it to tell" things, I think.
> 
> Pedro,
> I start to think about it today.  I don't see we have to adjust dcache.c 
> for disassembly and worry about the range.  From  GDB's point of view, 
> the process of reading a piece of stack memory should be identical to 
> reading a piece of code memory.  We are using '
> target_dcache' to cache stack memory, so we can also reuse it to cache 
> code memory.  Am I missing something?

Hmm, the idea was that having "disassemble $foo, $bar" read outside
[$foo,$bar) might not be safe (particularly so if the line size is
set large), as it might trip on memory mapped registers, which
might have side effects when read.  I guess I could be convinced that
this is overzealous?

BTW, how will your "Read memory in multiple lines in dcache_xfer_memory"
series help disassembly if the disassembler, today, without that other
patch that caches things in disasm.c, fetches memory from the target
instruction by instruction?  Seems to me it'll end up always fetching
a single line at a time.

-- 
Pedro Alves


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