From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15365 invoked by alias); 9 Oct 2015 12:51:17 -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 14483 invoked by uid 89); 9 Oct 2015 12:51:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 09 Oct 2015 12:51:15 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 8319E91E9F; Fri, 9 Oct 2015 12:51:14 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t99CpCvQ006368; Fri, 9 Oct 2015 08:51:13 -0400 Message-ID: <5617B840.7040504@redhat.com> Date: Fri, 09 Oct 2015 12:51:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Markus Metzger , dje@google.com CC: gdb-patches@sourceware.org Subject: Re: [PATCH 2/6] disasm: add struct disas_insn to describe to-be-disassembled instruction References: <1442847283-10200-1-git-send-email-markus.t.metzger@intel.com> <1442847283-10200-3-git-send-email-markus.t.metzger@intel.com> In-Reply-To: <1442847283-10200-3-git-send-email-markus.t.metzger@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-10/txt/msg00089.txt.bz2 On 09/21/2015 03:54 PM, Markus Metzger wrote: > Add a new struct disas_insn to add additional fields describing the > to-be-disassembled instruction. The additional fields are: > > number an optional instruction number, zero if omitted. > is_speculative a predicate saying whether the instruction was > executed speculatively. > > Replace the PC parameter of dump_insn with a pointer to the above struct. > > If non-zero, the instruction number is printed first. It will also appear > as a new optional field "insn-number" in MI. The field will be present if > insn_num is non-zero. > > If is_speculative is set, speculative execution will be indicated by a "?" > following the new instruction number field. Unless the PC is omitted, it > will overwrite the first byte of the PC prefix. It will appear as a new > optional field "is-speculative" in MI. The field will contain "?" and will > be present if is_speculative is set. > I think the log would be much clearer if the rationale was specified in terms of why this is necessary, and if we saw a before/after example. Also, being a user/frontend visible change, shouldn't these new fields be documented and mentioned in NEWS? > --- a/gdb/disasm.h > +++ b/gdb/disasm.h > @@ -27,11 +27,25 @@ > #define DISASSEMBLY_FILENAME (0x1 << 3) > #define DISASSEMBLY_OMIT_PC (0x1 << 4) > #define DISASSEMBLY_SOURCE (0x1 << 5) > +#define DISASSEMBLY_SPECULATIVE (0x1 << 6) > > struct gdbarch; > struct ui_out; > struct ui_file; > > +/* An instruction to be disassembled. */ > + > +struct disas_insn { { goes on the next line. Thanks, Pedro Alves