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 0/6] disasm, record: fix "record instruction-history /m"


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

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