From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8635 invoked by alias); 27 Nov 2012 17:33:44 -0000 Received: (qmail 8626 invoked by uid 22791); 27 Nov 2012 17:33:43 -0000 X-SWARE-Spam-Status: No, hits=-7.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Nov 2012 17:33:37 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qARHXUGF026991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 12:33:30 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qARHXSeA012887; Tue, 27 Nov 2012 12:33:28 -0500 Message-ID: <50B4F968.8080202@redhat.com> Date: Tue, 27 Nov 2012 17:33:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Metzger, Markus T" CC: "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" , "jan.kratochvil@redhat.com" , "tromey@redhat.com" , "kettenis@gnu.org" Subject: Re: [patch v4 01/13] disas: add precise instructions flag References: <1354013351-14791-1-git-send-email-markus.t.metzger@intel.com> <1354013351-14791-2-git-send-email-markus.t.metzger@intel.com> <50B4EF0E.8080102@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-11/txt/msg00760.txt.bz2 On 11/27/2012 05:26 PM, Metzger, Markus T wrote: >> From: Pedro Alves [mailto:palves@redhat.com] >>> the addresses that >>> are being disassembled may not exactly match the specified range. >> >> Is this another symptom of the issue that "disasm /m" sorts by >> line number, rather than the much more reasonable sort-by-address, >> which is IIRC what objdump does too? > > Yes. I didn't want to go that far. > > The patch is incomplete. It merely truncates the first and last block that gdb prints. If you wanted to change the behavior of "disasm /m", anyway, we can discard this patch. Sort-by-address is exactly what I'm looking for. Is somebody already working on this? I've never heard of anyone who actually likes the current behavior. On the contrary, I've heard several of the gdb developers wanting it the other way. But I'm not aware of anyone working on it. I'm not sure how hard is it to implement. Both gdb and objdump use libopcodes to disassemble, so one would think that it's quite doable. I think a wrinkle may be that the TUI uses the same code and the current sorting may (or not) make sense there I think the /m flag was just implemented as reusing the TUI code to begin with. -- Pedro Alves