public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tristan Gingold <gingold@adacore.com>
To: Nick Clifton <nickc@redhat.com>
Cc: binutils@sourceware.org, gdb-patches@sourceware.org
Subject: Re: RFC: Prevent disassembly beyond symbolic boundaries
Date: Fri, 19 Jun 2015 07:13:00 -0000	[thread overview]
Message-ID: <3D81F97D-90EA-4769-8381-514BB6E81E3F@adacore.com> (raw)
In-Reply-To: <87lhfhynoz.fsf@redhat.com>

Nick,

>  Currently objdump will disassemble beyond a symbolic boundary if it
>  needs extra bytes to decode an instruction.  For example (with x86):
> 
>        .file   "foo.c"
>        .text
>        .globl  foo
>        .type   foo, @function
>    foo:
>        .byte 0x24
>        .byte 0x2f
>        .byte 0x83
>        .size   foo, .-foo
> 
>        .globl bar
>        .type bar, @function
>    bar:
>        .byte 0x0f
>        .byte 0xba
>        .byte 0xe2
>        .byte 0x03
>        .size   bar, .-bar
> 
>  This will disassemble as:
> 
>    0000000000000000 <foo>:
>       0:   24 2f                   and    $0x2f,%al
>       2:   83 0f ba                orl    $0xffffffba,(%rdi)
> 
>    0000000000000003 <bar>:
>       3:   0f ba e2 03             bt     $0x3,%edx
> 
>  Note how the instruction decoded at address 0x2 has stolen two bytes
>  from "foo", but these bytes are also decoded (correctly this time) as
>  part of the first instruction of foo.
> 
>  I have a patch (attached) which changes this behaviour, so that the
>  disassembly would be:
> 
>       0:  24 2f              	   and    $0x2f,%al
>       2:  83                      .byte 0x83
> 
>    00000003 <bar>:
>       3:  0f ba e2 03             bt     $0x3,%edx

[…]

>  What do people think ?  To me this seems like a good idea, but I
>  willing to consider alternative suggestions if people have them.

I am curious.  Why do you think it was a problem ?
Even if there is a symbol in the middle of an instruction, I’d like
to understand what the processor will execute.  Before the proposed
change, it was possible, but after it isn’t easy anymore.

(But I agree I never met this issue.  I am just curious here).

Tristan.

  reply	other threads:[~2015-06-19  7:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-18 16:40 Nick Clifton
2015-06-19  7:13 ` Tristan Gingold [this message]
2015-06-19 11:41   ` Nicholas Clifton
2015-06-19 16:33     ` Tristan Gingold
2015-06-22 16:13       ` Nicholas Clifton

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=3D81F97D-90EA-4769-8381-514BB6E81E3F@adacore.com \
    --to=gingold@adacore.com \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    --cc=nickc@redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).