From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59527 invoked by alias); 12 Oct 2015 08:59:08 -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 59517 invoked by uid 89); 12 Oct 2015 08:59:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-wi0-f174.google.com Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com) (209.85.212.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 12 Oct 2015 08:59:07 +0000 Received: by wicgb1 with SMTP id gb1so140238024wic.1 for ; Mon, 12 Oct 2015 01:59:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=DMKOYGxMaFY/hZtAlISWosN+lfXK8l2FRZJX7Hg8QDU=; b=WgR1HVfYMrmYwcz/GGvCyd8qPSfvD04m87QVjFooUBp2TzBljzzBegDpp2t872mHvA myE2GdO8wCOvQPIv2UPYKIt296YlzFqNG3RTUUqpSF0bW9tYfqI5QfpCAIChFpElpp+2 lEmhlb9myT8H3LfcSagncRQEBDkB9zermkXceqeDnn6Sp8eCid5y/+WBVoMaajWEHO8O PdR1yWuQlOG5f6ktENT4FSxxlUYm0lNi2ErjEQQkFpALTf/9zwHev0Bt5Tqx/ObvQTPu XutaES+P0nos04KikoAd7GfOUpgF5a3uQzGwW2eMHROmxBDq2H6jTJ1knIZFudfojdo8 8qmw== X-Gm-Message-State: ALoCoQlIvhU7delo3hICEkaNSUpV/aY2LEPTJufIeeqp4YY7HayJYC91ue74or4TrIG9tJlCEBM9 X-Received: by 10.180.12.206 with SMTP id a14mr12035567wic.25.1444640343870; Mon, 12 Oct 2015 01:59:03 -0700 (PDT) Received: from localhost (TK158115.telekabel.at. [195.34.158.115]) by smtp.gmail.com with ESMTPSA id uj4sm18527257wjc.34.2015.10.12.01.59.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Oct 2015 01:59:03 -0700 (PDT) Date: Mon, 12 Oct 2015 08:59:00 -0000 From: Andrew Burgess To: "Metzger, Markus T" Cc: Pedro Alves , "dje@google.com" , "gdb-patches@sourceware.org" Subject: Re: [PATCH 3/6] disas: add gdb_disassembly_vec Message-ID: <20151012085901.GA12446@embecosm.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00142.txt.bz2 * Metzger, Markus T [2015-10-09 13:16:30 +0000]: > > -----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. This is definitely not correct. This is probably a sensible assumption for CLI users, however, disassemble requests from the MI are frequently larger, and based around address ranges, happily spanning both function and compilation unit boundaries. The reason is that the driver might be trying to fill a possibly large window (with look ahead) with disassembled instructions; at the same time the driver will ask for the source information so that the user can click a disassembled instruction and instantly be taken to the corresponding source line. I guess whether this is a "large" number of instruction is up for debate, but I think we should assume that a couple of hundred is not out of the question. I don't know if this makes much of a difference to your proposed change, but please do bear this in mind. Thanks, Andrew