Questions about ld h->pointer_equality_needed on x86-64

[Michael Matz]

Hello,

On Fri, 28 Mar 2025, Jan Beulich wrote:

> > The pointer_equality_needed flag is basically set optimistically to false 
> > on x86-64 (in the sense that it's sometimes not set, even though it would 
> > be correct to do so).  Only in situations where we know that a use 
> > certainly must be an address-taken, do we set it.  PC32 in non-CODE 
> > sections fits that, it's unrealistic to have that situation and then not 
> > somehow using the address such that equality might matter.  For PC32 in 
> > CODE sections, again see above.  It could be a non-address-use, so we 
> > don't record it as address-use.
> > 
> > PC32S is similar, just that it cannot occur (realistically) in non-CODE 
> > sections anyway, so all occurrences are regarded as 
> > might-be-non-address-use.
> 
> Why only non-CODE? Especially in the kernel memory model data (pointers)
> can be expressed this way as all. Recall that even a special .slong
> directive was added to gas at some point, to be able to control the
> involved relocation.
> 
> (For context: I'm sure you mean 32S here.)

(That's what I meant, yes.)  As you said: "can" be expressed.  Yes, it's 
possible.  Does it realistically happen in contexts where 
pointer_equality_needed matters (i.e. symbols involving either a canonical 
PLT or copy reloc)?  Obviously not, otherwise we wouldn't have gone away 
with it :-)  I basically tried to explain why that flag is set 
inconsistently but wanted to avoid saying "because we get away with it, 
and it allows more existing code to be assembled".

When a use case comes up, outside test cases, that actually tries to 
encode kernel mode pointers in signed 32bit quantities in data sections of 
a position dependend segment, and that involves symbols from shared 
objects, and that uses address comparisons on those symbols, then 32S 
handling can be made similar, i.e. the non-CODE condition be 
added.

Or we could change that now, for consistency sake, and see what breaks in 
the wild.  I'm usually not a fan of that, there is _always_ something 
old and strange in a linux distro that breaks :-)


Ciao,
Michael.