Re: [PATCH] x86: Disallow ".long foo@PLT - .L4" for PLT32 relocation

On 03.08.2026 19:46, Maciej W. Rozycki wrote:
> On Mon, 3 Aug 2026, H.J. Lu wrote:
> 
>>>>>>>>  Jan, please correct me if I'm wrong since commit d182319b0955 has no
>>>>>>>> change description and there's no documentation for `.slong' in the GAS
>>>>>>>> manual either.  What are the x86 psABI ELF relocation types corresponding
>>>>>>>> to `.long' and `.slong' respectively in this context?
>>>>>>>
>>>>>>> For .long there simply is no correct relocation type to use for PLT (and,
>>>>>>> fwiw, simple PC-relative) expressions. The correct type to use is
>>>>>>> R_X86_64_PLT32 (and R_X86_64_PC32 for the simple PC-rel case).
> 
>  Would you please provide me with the calculation R_X86_64_PLT32 stands 
> for and what the calculation required would be for `.long' should we have 
> an actual relocation representing this operation?

L + A - P

with the usual meaning of

L - address of PLT entry for the referenced symbol
A - addend
P - address of the storage unit being relocated

>  Also what is the linker 
> expected by the psABI to do on an overflow condition?

Since the result has to be a valid (64-bit) address, sign-extension is
necessary, and hence the overflow condition has to match that (starting
from the 32-bit input field).

>>>>>>> For the simple PC-rel case we simply cannot require use of .slong, as we've
>>>>>>> been accepting .long (then guessing that .slong was meant). Else we'd very
>>>>>>> likely break existing code. Since @PLT was rejected so far when used with
>>>>>>> .long and .slong, doing better here is imo very desirable (if not
>>>>>>> imperative).
> 
>  Ack, understood, although would perhaps an assembly warning be in order?  
> Does this case typically come from handwritten assembly or one of compiled 
> origin?

Both, hence imo a warning is out of question.

Jan