Home Original page

[PATCH 2/2] x86/APX: support JMPABS also in assembler

H.J. Lu hjl.tools@gmail.com
Fri Oct 11 01:49:09 GMT 2024 
On Fri, Oct 11, 2024, 9:41 AM Hu, Lin1 <lin1.hu@intel.com> wrote:

> > -----Original Message-----
> > From: Jan Beulich <jbeulich@suse.com>
> > Sent: Thursday, October 10, 2024 7:51 PM
> > To: Hu, Lin1 <lin1.hu@intel.com>
> > Cc: Binutils <binutils@sourceware.org>; Cui, Lili <lili.cui@intel.com>;
> H.J. Lu
> > <hjl.tools@gmail.com>
> > Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> >
> > On 10.10.2024 11:57, Hu, Lin1 wrote:
> > >> -----Original Message-----
> > >> From: Jan Beulich <jbeulich@suse.com>
> > >> Sent: Thursday, October 10, 2024 4:25 PM
> > >>
> > >> On 10.10.2024 09:51, Hu, Lin1 wrote:
> > >>>> -----Original Message-----
> > >>>> From: Jan Beulich <jbeulich@suse.com>
> > >>>> Sent: Thursday, October 10, 2024 3:05 PM
> > >>>> To: Hu, Lin1 <lin1.hu@intel.com>
> > >>>> Cc: Binutils <binutils@sourceware.org>; Cui, Lili
> > >>>> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>
> > >>>> Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> > >>>>
> > >>>> On 10.10.2024 03:53, Hu, Lin1 wrote:
> > >>>>> I don't think linker currently supports the following forms:
> > >>>>> label:
> > >>>>>         ...
> > >>>>>         jmpabs label
> > >>>>
> > >>>> Why would it not support this? It doesn't care at all what insn it
> > >>>> is; all it cares about is the associated relocation (R_X86_64_64
> for ELF).
> > And ...
> > >>>
> > >>> I'm not familiar with this part. Does assembler definitely generate
> > >> R_X86_64_64 rather than R_X86_64_GOTOFF64 or R_X86_64_PLTOFF64?
> > >>
> > >> The assembler won't invent PLTOFF or GOTOFF when the source doesn't
> > >> specify it. If there were @pltoff or @gotoff operators (or whatever
> > >> the correct forms
> > >> are) on the symbol, the assembler still has code to choke on wrong
> > >> uses. I didn't check though whether that would properly work here.
> > >>
> > >
> > > OK.
> > >
> > >>
> > >>>>> Same thing we discussed earlier, it's pointless to support this
> > >>>>> format now. And
> > >>>> for the form that uses label, maybe we can consider let linker to
> > >>>> convert 'jmp label''s encoding to jmpabs's. For gas, even if the
> > >>>> likelihood of a new instruction like 'jmpabs 0x521515' appearing is
> > >>>> small, that's no reason for us to accept this usage; we think it's
> > >>>> safer to let
> > >> the linker support it.
> > >>>>
> > >>>> ... how does the linker come into the picture here in the first
> place?
> > >>>
> > >>> We think it's safer to extend the 'jmp label' functionality in the
> > >>> linker without
> > >> any conflict with the documentation.
> > >>
> > >> That doesn't answer my question. Without that answered I'm also not
> > >> understanding your reply, I'm afraid.
> > >>
> > >
> > > At first, we worried that the linker wouldn't support "jmpabs label"
> (This
> > question may have already been answered). It's the root cause. And then
> from
> > my viewpoint, "jmpabs  0x123" isn't allowed, so we consider use another
> > method to let binutils's user use jmpabs, we think do a optimization in
> linker
> > convert jmp to jmpabs is safer.
> >
> > Just to mention it: Unless you mean JMPABS -> JMP conversion, the
> conversion
> > you mention won't be possible without help by the assembler, as you would
> > need to reserve more bytes in the section in order to fit the longer
> insn.
> > Or maybe you're thinking of inserting "trampoline thunks" (iirc Arm64
> calls such
> > "veneers"), themselves required to be within reach of the original JMP?
> >
>
> I didn't consider the code length issue at first. We should have a usage
> like "mov + jmp", I think we can consider do this conversion "mov + jmp ->
> jmpabs".
>

The reason we didn't add jmpabs to assembler is that
this instruction isn't designed for compilers nor assembler.
Its intended usages are for JITs.   Currently
glibc' ld.so will rewrite PLT entries with jmpabs if enabled
at runtime.
"jmpabs $foo" should be the only valid syntax.


> BRs,
> Lin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20241011/23940546/attachment.htm>
More information about the Binutils mailing list