RE: [patch] Disassembly improvements

["Abid, Hafiz" <Hafiz_Abid@mentor.com>]

> Question: How much more of the general problem can we fix without having
> a fix baked into the disassembler?
Perhaps we can improve GDB memory caching to handle this case instead of baking
a solution into disassembler. I am not very familiar with dcache.c but I will 
investigate if we can extend that approach. Any guidance is welcome offcourse.

> -----Original Message-----
> From: Doug Evans [mailto:dje@google.com]
> Sent: 11 October 2013 22:34
> To: Abid, Hafiz
> Cc: Pedro Alves <palves@redhat.com> (palves@redhat.com); gdb-
> patches@sourceware.org; Mirza, Taimoor
> Subject: Re: [patch] Disassembly improvements
> 
> On Thu, Oct 10, 2013 at 6:14 AM, Abid, Hafiz <Hafiz_Abid@mentor.com>
> wrote:
> > Hi Pedro,
> > I am attaching the patch that was mentioned in the following thread. I
> resurrected it from our internal repo, did a bit of manual testing and run the
> regression suite without any problem. It basically reads memory from the
> target in a buffer in gdb_disassembly and tries to use this buffer in
> dis_asm_read_memory instead of reading from the target. This saves us on
> repeated memory read calls. The problem was noted when eclipse was trying
> to fill its disassembly view.
> > https://sourceware.org/ml/gdb-patches/2013-10/msg00221.html
> >
> > Regards,
> > Abid
> >
> > 2013-10-10  Taimoor Mirza  <taimoor_mirza@mentor.com>
> >
> >         * disasm.c (DIS_BUF_SIZE): New define.
> >         (dis_asm_read_memory): Read from the disassembly buffer instead
> >         of target memory directly.
> >         (gdb_disassembly): Fill the disassembly buffer with a chunk of
> >         the memory to disassemble.
> 
> This is a specific fix to a general problem.
> Question: How much more of the general problem can we fix without having
> a fix baked into the disassembler?