public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	"Binutils" <binutils@sourceware.org>,"Michael Matz"
	<matz@suse.de>
Subject: Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches
Date: Fri, 15 May 2015 06:39:00 -0000	[thread overview]
Message-ID: <5555B0C2020000780007A5FB@mail.emea.novell.com> (raw)
In-Reply-To: <CAMe9rOo-K21Gs9prT6Tb4nX80VRi2bA26mGonnr7=vt8W1NFKA@mail.gmail.com>

>>> On 13.05.15 at 18:53, <hjl.tools@gmail.com> wrote:
> On Wed, May 13, 2015 at 9:50 AM, Maciej W. Rozycki <macro@linux-mips.org> 
> wrote:
>> On Wed, 13 May 2015, H.J. Lu wrote:
>>
>>> >> > Well, what do you suggest?  Your change is clearly wrong as well.
>>> >>
>>> >> I won't call it wrong since it implies there is a right.
>>> >
>>> > Of course there is a right.  The x86-64 specification is quite clear what
>>> > happens with the prefix on jumps.  Intel CPUs are simply buggy in not
>>> > implementing it.  And you're making binutils follow that buggy behaviour.
>>>
>>> AMD64 and Intel64 differ in some subtle ways.
>>>
>>> > And that is wrong.  The associated bug report is invalid.
>>>
>>> How about this
>>>
>>> 1.  Add flavors of AMD64 and Intel64 to assembler.  Make the most
>>> permissive one as the default.  In case of call/jmp, the default will
>>> take AMD64.
>>> 2.  Add -Mintel64/-Mamd64 to objdump,  Make the most permissive
>>> ones the default.
>>
>>  FWIW I think this will be the right direction, though the exact options
>> may have to be discussed yet.
>>
>>  The assembler is a tool, it should not be forcing a use policy upon
>> users.  Therefore it should allow whatever is encodable given the
>> instruction set definition and let users decide themselves how to use
>> it, whether implementations follow the rules or not.
>>
>>  And then if you want to add safety traps such as for this difference
>> between individual model implementations, then wire them to `-march=' or
>> suchlike.
> 
> Thanks for your feedbacks.  I am waiting for feedbacks from Jan and
> Michael before I start investigation.

Not sure what else feedback you expect - after all I had suggested
the introduction of command line options or alike to control the
specific behavior. All I'm really after is that without any such override
given behavior remain like what it is in 2.25.

Jan

  reply	other threads:[~2015-05-15  6:39 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-11 21:23 H.J. Lu
2015-05-12 10:41 ` Jan Beulich
2015-05-12 11:54   ` H.J. Lu
2015-05-12 12:20     ` Jan Beulich
2015-05-12 12:37       ` H.J. Lu
2015-05-12 13:03         ` Jan Beulich
2015-05-12 13:37           ` H.J. Lu
2015-05-12 13:49             ` Michael Matz
2015-05-12 13:57               ` H.J. Lu
2015-05-12 14:31                 ` Michael Matz
2015-05-12 14:49                   ` H.J. Lu
2015-05-12 15:14                     ` Michael Matz
2015-05-12 15:21                       ` H.J. Lu
2015-05-12 15:32                         ` Michael Matz
2015-05-12 14:59             ` Jan Beulich
2015-05-12 15:03               ` H.J. Lu
2015-05-12 15:09                 ` Jan Beulich
2015-05-12 15:11                   ` H.J. Lu
2015-05-12 15:17                     ` Jan Beulich
2015-05-12 15:37                       ` Michael Matz
2015-05-12 15:43                         ` H.J. Lu
2015-05-12 15:47                           ` Michael Matz
2015-05-12 16:00                             ` H.J. Lu
2015-05-12 16:03                               ` Michael Matz
2015-05-12 16:08                                 ` H.J. Lu
2015-05-13  6:18                                   ` Jan Beulich
2015-05-13 11:35                                     ` H.J. Lu
2015-05-13 12:27                                       ` Jan Beulich
2015-05-13 13:15                                         ` H.J. Lu
2015-05-13 12:34                                   ` Michael Matz
2015-05-13 13:32                                     ` H.J. Lu
2015-05-13 16:50                                       ` Maciej W. Rozycki
2015-05-13 16:53                                         ` H.J. Lu
2015-05-15  6:39                                           ` Jan Beulich [this message]
2015-05-15 16:52                                             ` H.J. Lu
2015-05-18  7:05                                               ` Jan Beulich
2015-05-18 11:22                                                 ` H.J. Lu
2015-05-18 11:48                                                   ` Jan Beulich
2015-05-18 12:18                                                     ` H.J. Lu

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=5555B0C2020000780007A5FB@mail.emea.novell.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=macro@linux-mips.org \
    --cc=matz@suse.de \
    /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).