From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85650 invoked by alias); 18 Oct 2015 20:39:42 -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 85640 invoked by uid 89); 18 Oct 2015 20:39:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f175.google.com Received: from mail-yk0-f175.google.com (HELO mail-yk0-f175.google.com) (209.85.160.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 18 Oct 2015 20:39:40 +0000 Received: by ykfy204 with SMTP id y204so126296202ykf.1 for ; Sun, 18 Oct 2015 13:39:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.41.148 with SMTP id p142mr19680717ywp.274.1445200777985; Sun, 18 Oct 2015 13:39:37 -0700 (PDT) Received: by 10.13.243.193 with HTTP; Sun, 18 Oct 2015 13:39:37 -0700 (PDT) In-Reply-To: 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> Date: Sun, 18 Oct 2015 20:39:00 -0000 Message-ID: Subject: Re: [PATCH 3/6] disas: add gdb_disassembly_vec From: Doug Evans To: "Metzger, Markus T" Cc: Pedro Alves , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00319.txt.bz2 On Fri, Oct 9, 2015 at 6:16 AM, Metzger, Markus T wrote: >> -----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. Thousands of instructions is something we need to handle, as is very large source files (I've seen machine generated source files that aren't small). For reference sake, one concern I have is a very large source file with a very large function at the end. IIUC, the current patch is O(NxM). [N = #lines with code in source file, M = #instructions being disassembled]