Re: [PATCH 0/6] disasm, record: fix "record instruction-history /m"

[Doug Evans <xdje42@gmail.com>]

On Mon, Oct 12, 2015 at 7:16 AM, Metzger, Markus T
<markus.t.metzger@intel.com> wrote:
>> -----Original Message-----
>> From: Metzger, Markus T
>> Sent: Monday, September 21, 2015 4:55 PM
>> To: palves@redhat.com; dje@google.com
>> Cc: gdb-patches@sourceware.org
>> Subject: [PATCH 0/6] disasm, record: fix "record instruction-history /m"
>
>
>> Markus Metzger (6):
>>   disasm: change dump_insns to print a single instruction
>>   disasm: add struct disas_insn to describe to-be-disassembled
>>     instruction
>>   disas: add gdb_disassembly_vec
>>   disasm: use entire line table in line_has_code_p
>>   disasm: determine preceding lines independent of last_line
>>   btrace: use gdb_disassembly_vec and new source interleaving method
>
> Given the concerns about increased memory consumption and run-time
> overhead in patch 3 and the changes to the source interleaving algorithm
> in patches 4 and 5, I'd go with a modified version of my original RFC, i.e.
>
>   - patches 1 and 2 from this series
>   - the rfc patch to interleave sources in record-btrace.c
>   - patch 6 from this series
>
> This will leave us with two source interleaving algorithms, one for a
> consecutive range of memory, and one for a sequence of instructions
> in the order in which they were recorded.
>
> Both will use a slightly modified dump_insn to print instruction tuples.
>
> I'm dropping the idea of preparing a vector of instructions to print and
> and of trying to shoehorn record instruction-history's source interleaving
> into do_mixed_source_and_assembly.
>
> Does that sound OK?

I think so (devil is in the details).
Supporting a vector of instructions sounds fine to me though.
There doesn't have to be one entry point to the disassembler API.
[5 would be bad, but 2 is ok: one that takes a range, one that takes a vector.]