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

Doug Evans
2015-10-18T21:17:12Z

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.]