From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38431 invoked by alias); 9 Oct 2015 13:17:41 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 38411 invoked by uid 89); 9 Oct 2015 13:17:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Oct 2015 13:17:38 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 09 Oct 2015 06:17:36 -0700 X-ExtLoop1: 1 Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga001.jf.intel.com with ESMTP; 09 Oct 2015 06:17:35 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.150]) by IRSMSX107.ger.corp.intel.com ([169.254.10.49]) with mapi id 14.03.0248.002; Fri, 9 Oct 2015 14:16:30 +0100 From: "Metzger, Markus T" To: Pedro Alves , "dje@google.com" CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH 3/6] disas: add gdb_disassembly_vec Date: Fri, 09 Oct 2015 13:17:00 -0000 Message-ID: References: <1442847283-10200-1-git-send-email-markus.t.metzger@intel.com> <1442847283-10200-4-git-send-email-markus.t.metzger@intel.com> <5617B7E6.1070101@redhat.com> In-Reply-To: <5617B7E6.1070101@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00091.txt.bz2 > -----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 >=20 > 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. >=20 > 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 >=20 > (gdb) disassemble 0x3000000000,0x7000000000 >=20 > 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