This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Markus Metzger <markus.t.metzger@intel.com> writes:
> The /m modifier interleaves source lines with the disassembly of recorded
> instructions.  This calls disasm.c's do_mixed_source_and_assembly once for
> each recorded instruction to be printed.
>
> The latter really does a source print with intermixed disassembly.  To that
> purpose, it may reorder instructions to better match the source.  This doesn't
> work for printing a single instruction.  The output also interferes with
> "record instruction-history" specific extensions.
>
> Change record instruction-history /m to use its own simple source interleaving
> algorithm.  The most important part is that instructions are printed in
> the order in which they were executed.  Before each instruction, we print
> a range of source lines that are attributed to the instruction's PC.  If the
> source line range has already been printed (or skipped) for the previous
> instruction, we skip it.
>
> This is a mixture of an earlier RFC that added source interleaving to the
> "record instruction-history" command and version 1 of this patch series that
> tried to modify Doug Evans new "disassembly" source interleaving algorithm and
> use it for "record instruction-history", as well.
>
> We extend disasm.c's insn tuple printing and use it for printing a single
> instruction.  To also share the source interleaving algorithm, we'd need to
> change it significantly.  When building a hash table of source lines of the
> memory range to disassemble and when inserting lines without source code, the
> algorithm assumes that instructions are printed in the order in which they
> appear in memory.  The "record instruction-history" command needs to print
> instructions in the order in which they retired.
>
> I propose to leave the two source interleaving algorithms separate.

Hi.

This proposal is fine by me.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]