From: Doug Evans <dje@google.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA] amd64 displaced stepping support
Date: Wed, 28 Jan 2009 00:13:00 -0000 [thread overview]
Message-ID: <e394668d0901271531q3de2f490v74418924a82eb6fd@mail.gmail.com> (raw)
In-Reply-To: <20090127172730.GA3749@caradoc.them.org>
On Tue, Jan 27, 2009 at 9:27 AM, Daniel Jacobowitz <drow@false.org> 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).
next prev parent reply other threads:[~2009-01-27 23:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-27 1:33 Doug Evans
2009-01-27 8:26 ` Stan Shebs
2009-01-27 17:27 ` Pedro Alves
2009-01-28 12:39 ` Doug Evans
2009-01-28 14:34 ` Pedro Alves
2009-01-28 15:05 ` Daniel Jacobowitz
2009-01-27 20:27 ` Daniel Jacobowitz
2009-01-28 0:13 ` Doug Evans [this message]
2009-01-28 14:37 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e394668d0901271531q3de2f490v74418924a82eb6fd@mail.gmail.com \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox