This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [PATCH 3/6] disas: add gdb_disassembly_vec
- From: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- To: Pedro Alves <palves at redhat dot com>, "dje at google dot com" <dje at google dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 9 Oct 2015 13:16:30 +0000
- Subject: RE: [PATCH 3/6] disas: add gdb_disassembly_vec
- Authentication-results: sourceware.org; auth=none
- References: <1442847283-10200-1-git-send-email-markus dot t dot metzger at intel dot com> <1442847283-10200-4-git-send-email-markus dot t dot metzger at intel dot com> <5617B7E6 dot 1070101 at redhat dot com>
> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Friday, October 9, 2015 2:50 PM
> To: Metzger, Markus T; dje@google.com
> Cc: gdb-patches@sourceware.org
> Subject: Re: [PATCH 3/6] disas: add gdb_disassembly_vec
>
> On 09/21/2015 03:54 PM, Markus Metzger wrote:
> > Add a new function to disassemble a vector of instructions instead of a
> > contiguous range of instructions. The instructions can be in any order
> > and may originate from different functions.
> >
> > Change gdb_disassembly to create a vector of instructions from its low,
> > high, and how_many arguments.
>
> I wonder whether the representation could/should be based on a vector
> of struct mem_range's instead of a vector of instructions. I'm assuming
> the normal case is that we're disassembling ranges of more than
> one instruction. Just seems wasteful for something like
>
> (gdb) disassemble 0x3000000000,0x7000000000
>
> to allocate so much memory. But maybe I simply misunderstood.
You didn't. It really is a vector of instructions - we do need additional information
for each instruction (see [PATCH 2/6]). Also the instructions come in the order
in which they were executed; not in the order of their memory address.
I expected the normal usage of "disassemble" to be one function or maybe
a few dozen instructions at a time.
If we really want to support many thousands of instructions, the whole idea
breaks down. We'd rather keep the two algorithms separate or we break
the disassemble algorithm apart so that the components can be reused.
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