Home Original page

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

Hu, Lin1 lin1.hu@intel.com
Fri Oct 11 01:41:28 GMT 2024 
> -----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".

BRs,
Lin
More information about the Binutils mailing list