From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10923 invoked by alias); 27 Jan 2009 23:31:51 -0000 Received: (qmail 10912 invoked by uid 22791); 27 Jan 2009 23:31:51 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Jan 2009 23:31:45 +0000 Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id n0RNVfnT032656 for ; Tue, 27 Jan 2009 23:31:42 GMT Received: from rv-out-0506.google.com (rvbk40.prod.google.com [10.140.87.40]) by wpaz17.hot.corp.google.com with ESMTP id n0RNVdo0029213 for ; Tue, 27 Jan 2009 15:31:39 -0800 Received: by rv-out-0506.google.com with SMTP id k40so17411266rvb.19 for ; Tue, 27 Jan 2009 15:31:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.50.11 with SMTP id c11mr2621663rvk.45.1233099098943; Tue, 27 Jan 2009 15:31:38 -0800 (PST) In-Reply-To: <20090127172730.GA3749@caradoc.them.org> References: <20090126230013.5C7F01C72DE@localhost> <20090127172730.GA3749@caradoc.them.org> Date: Wed, 28 Jan 2009 00:13:00 -0000 Message-ID: Subject: Re: [RFA] amd64 displaced stepping support From: Doug Evans To: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2009-01/txt/msg00522.txt.bz2 On Tue, Jan 27, 2009 at 9:27 AM, Daniel Jacobowitz wrote: > On Mon, Jan 26, 2009 at 03:00:12PM -0800, Doug Evans wrote: >> Using the disassembler to compute instruction lengths is awkward, I know. >> It's needed in order to compute the address of rip-relative addressing. >> The address is %rip + address-of-next-insn + displacement, >> and the displacement is only 32 bits so it's not guaranteed to be enough >> to cover the distance between the original instruction and its copy. >> To compensate I compute an unused integer reg, set it to >> %rip + address-of-next-insn, and rewrite the insn to use base+disp addressing. >> I think the GNU tools need a general-purpose library of ISA-related tools. >> Until then, I went with the disassembler. The code is laid out such that >> when a better implementation of computing insn lengths comes along, it >> can be easily dropped in. > > IMO, "the disassembler" means a bit of GDB interface glue, and > libopcodes. Libopcodes is the obvious place for a library about > opcodes. It can export more information; there's an example of this > at the very end of struct disassemble_info, though it probably needs > more granularity. I don't disagree that libopcodes is a reasonable place. I'm assuming by "example of this" you're refering to branch_delay_insns, target, target2, etc. Right? This is great stuff, but it's in a struct named "disassemble_info". :-) IWBN if libopcodes could provide a more generic interface, and long term an interface more suitable to general use (i.e. not restricted to the confines of gdb/binutils releases).