[PATCH 3/6] disas: add gdb_disassembly_vec

Doug Evans xdje42@gmail.com
Sun Oct 18 20:39:00 GMT 2015


On Fri, Oct 9, 2015 at 6:16 AM, Metzger, Markus T
<markus.t.metzger@intel.com> wrote:
>> -----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.
>
> If we really want to support many thousands of instructions, the whole idea
> breaks down.  We'd rather keep the two algorithms separate or we break
> the disassemble algorithm apart so that the components can be reused.

Thousands of instructions is something we need to handle,
as is very large source files (I've seen machine generated source
files that aren't small).
For reference sake, one concern I have is a very large source file
with a very large function at the end. IIUC, the current patch is O(NxM).
[N = #lines with code in source file, M = #instructions being disassembled]



More information about the Gdb-patches mailing list