This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [PATCH 0/6] disasm, record: fix "record instruction-history /m"
- From: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- To: Doug Evans <xdje42 at gmail dot com>
- Cc: "palves at redhat dot com" <palves at redhat dot com>, "dje at google dot com" <dje at google dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 19 Oct 2015 09:35:18 +0000
- Subject: RE: [PATCH 0/6] disasm, record: fix "record instruction-history /m"
- Authentication-results: sourceware.org; auth=none
- References: <1442847283-10200-1-git-send-email-markus dot t dot metzger at intel dot com> <A78C989F6D9628469189715575E55B23331E6206 at IRSMSX104 dot ger dot corp dot intel dot com> <CAP9bCMS0rehaE__iBmSVtneS2EFDoOuvWWJOdBqo9U6aBfP6yA at mail dot gmail dot com>
> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Doug Evans
> Sent: Sunday, October 18, 2015 11:17 PM
> To: Metzger, Markus T
> Cc: palves@redhat.com; dje@google.com; gdb-patches@sourceware.org
> Subject: Re: [PATCH 0/6] disasm, record: fix "record instruction-history /m"
Hi Doug,
> > 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.]
Patches 4 and 5 of this series modify the algorithm to make it work for instructions
in random order. I have to drop the source line hash table, for example, and
perform a much more expensive search.
Also if we don't want to create a temporary vector of instructions, I'd have to
extract the local variables into an iteration state struct and split the algorithm
into small pieces.
It's possible, of course, but I'm afraid you won't recognize your algorithm,
afterwards.
I sent v2 of the series as outlined above.
Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Prof. Dr. Hermann Eul
Chairperson of the Supervisory Board: Tiffany Doon Silva
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928