Re: [PATCH 3/6] disas: add gdb_disassembly_vec

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Metzger, Markus T <markus.t.metzger@intel.com> [2015-10-09 13:16:30 +0000]:

> > -----Original Message-----
> > From: Pedro Alves [mailto:palves@redhat.com]
> > Sent: Friday, October 9, 2015 2:50 PM
> > To: Metzger, Markus T; dje@google.com
> > Cc: gdb-patches@sourceware.org
> > Subject: Re: [PATCH 3/6] disas: add gdb_disassembly_vec
> > 
> > On 09/21/2015 03:54 PM, Markus Metzger wrote:
> > > Add a new function to disassemble a vector of instructions instead of a
> > > contiguous range of instructions.  The instructions can be in any order
> > > and may originate from different functions.
> > >
> > > Change gdb_disassembly to create a vector of instructions from its low,
> > > high, and how_many arguments.
> > 
> > I wonder whether the representation could/should be based on a vector
> > of struct mem_range's instead of a vector of instructions.  I'm assuming
> > the normal case is that we're disassembling ranges of more than
> > one instruction.  Just seems wasteful for something like
> > 
> >   (gdb) disassemble 0x3000000000,0x7000000000
> > 
> > to allocate so much memory.  But maybe I simply misunderstood.
> 
> You didn't.  It really is a vector of instructions - we do need additional information
> for each instruction (see [PATCH 2/6]).  Also the instructions come in the order
> in which they were executed; not in the order of their memory address.
> 
> I expected the normal usage of "disassemble" to be one function or maybe
> a few dozen instructions at a time.

This is definitely not correct.

This is probably a sensible assumption for CLI users, however,
disassemble requests from the MI are frequently larger, and based
around address ranges, happily spanning both function and compilation
unit boundaries.

The reason is that the driver might be trying to fill a possibly large
window (with look ahead) with disassembled instructions; at the same
time the driver will ask for the source information so that the user
can click a disassembled instruction and instantly be taken to the
corresponding source line.

I guess whether this is a "large" number of instruction is up for
debate, but I think we should assume that a couple of hundred is not
out of the question.

I don't know if this makes much of a difference to your proposed
change, but please do bear this in mind.

Thanks,
Andrew