[PATCH v3 10/10] x86-64: Intel64 adjustments for insns dealing with far pointers

H.J. Lu hjl.tools@gmail.com
Wed Jan 22 14:34:00 GMT 2020


On Wed, Jan 22, 2020 at 6:24 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 22.01.2020 14:21, H.J. Lu wrote:
> > On Mon, Jan 20, 2020 at 6:33 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 20.01.2020 14:42, H.J. Lu wrote:
> >>> On Mon, Jan 20, 2020 at 2:12 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 17.01.2020 19:06, H.J. Lu wrote:
> >>>>> On Fri, Jan 17, 2020 at 3:48 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> On 16.01.2020 21:24,  H.J. Lu  wrote:
> >>>>>>> We should improve gas documentation.  The current far branches
> >>>>>>> work fine.  Why bother to add new far branches without giving
> >>>>>>> developer a clue how to use them?
> >>>>>>
> >>>>>> That's the subject of CPU documentation, not that of any assembler.
> >>>>>> The current far branches "work fine" as far as they're being made
> >>>>>> accessible (encodable) by gas. The 64-bit forms Intel CPUs support
> >>>>>> didn't work fine at all (because one had to use hand crafted REX.W
> >>>>>> prefixes), as per Andrew's bug report. There's no difference here
> >>>>>> to the prior work you did to support the Intel64 / AMD64
> >>>>>> differences for certain other insns - you've simply made gas
> >>>>>> capable of properly encoding them in a vendor dependent manner.
> >>>>>> You didn't accompany this with any documentation explaining "how
> >>>>>> to use" these. If, retroactively, you think this should have been
> >>>>>> accompanied by such documentation, may I ask that you add such,
> >>>>>
> >>>>> Yes, it is not very obvious how to use them, we should add some
> >>>>> documentation.   Which one do you have in mind?
> >>>>
> >>>> All which currently have the Intel64 or AMD64 attribute. If all
> >>>> present ones had extra documentation, then (as said) it would be
> >>>> more obvious that _and_ what documentation needs/wants adding
> >>>> for ones covered anew.
> >>>
> >>> Let's start with one first.  Please name one.
> >>
> >> CALL r/m (and then naturally also JMP r/m).
> >
> > I used
> >
> > data16 jmp foo
> >
> > I think assembler should just support the common ISA.  If one wants more,
> > they can use REX prefix.  Now you added a new syntax.  You should document
> > it.
>
> I'm sorry, but we're moving in circles. I've previously indicated
> that I'd be fine to add documentation, as long as I know what
> precisely you're after, and what part of the documentation it is
> that you want to have extended (i.e. preferably where similar
> information for other stuff already exists). Adding something new
> has not typically been a reason to extend the documentation, when
> what has got added was a natural extension of what's been there
> before. Or else there would be mention of how to use various
> other insns; first an foremost there would be mention of all the
> 64-bit extensions to pre-existing 32-bit insns back when x86-64
> support was added.
>
> Once again, give me a handle on what you want me to do, or be so
> kind and supply the pieces yourself (either for me to merge into
> the patch, or to commit later on top of it). Please excuse my
> ignorance, but I _simply don't see_ what needs documenting here
> given the documentation that is available. And I don't see
> myself start from scratch something entirely new.
>

We should add a new section to document different mnemonics between
Intel64 and AMD64 , something like "lcall  *(%rax)" is common and
"lcallq  *(%rax)" is for Intel64 with REX_W.


-- 
H.J.



More information about the Binutils mailing list