Re: [PATCH v5 02/24] x86/elf, um/x86/elf: Move relocation constants to UAPI

[Thomas Weißschuh]

On Wed, Sep 09, 2026 at 07:49:30AM -0700, Borislav Petkov wrote:
> On Wed, Sep 09, 2026 at 07:59:51AM +0200, Thomas Weißschuh wrote:
> > These names and numbers are defined by the architectures' ELF specifications.
> > They are already cast in stone. For example see Table 4.9 of [0].
> > Changing them would break compilers, linkers, loaders and more or less every
> > existing ELF binary.
> 
> So?

This was a direct response to your "And putting them in UAPI casts them in
stone". With the idea that we can't possibly cast them more into stone
than they already are.

> Your goal is to provide them to tools/. You want to provide them to
> *everything*. See the discrepance here?

My goal is to make my tool work. For that I can just as well add ad-hoc
relocation constants definitions in my own code. Just as everybody else
has done, in what seems like a well-honed tradition.
Unifying the constant definitions was a preparatory cleanup step I put
in my series.

Some architectures (like x86) define the relocation constants in internal
kernel headers, but others do so in their UAPI headers, so we can't have it
in include/linux/.
As the UAPI is the common superset, and given that we already have quite some
ELF definitions in the UAPI I this is where I put the relocation constants.
We can add a tools/-specific header which is not shared with include/linux/
but then we still have duplication with the regular kernel code.

As a coincidence, these definitions in the UAPI would also be useful
for nolibc static PIE support, but that is more of a weird curiousity
and not something I want to bring up as reason here.

(...)

> > Also we already have other, closely related, ELF constants in the UAPI,
> > see {,tools/}include/uapi/linux/elf{,-em}.h.
>
> Srsly?!?
> 
> You moved them there:
> 
> commit 626fd35278295fbb21f2da331cd8028e9738d965
> Author: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxxxx>
> Date:   Wed Feb 26 12:44:46 2025 +0100
> 
>     tools/include: Add uapi/linux/elf.h
>     
>     It will be used by the vDSO selftests.

I think we are talking past each other. To me the act of "exposing
something to UAPI" is adding it to include/uapi/ (or the arch/ variants).
That is an actual change worthy of discussion, which I am happy to have.
Copying headers (UAPI or not) to tools/include/ is a rote administrative task.

The commit above is the latter.
elf.h has been part of the UAPI for as long as the UAPI exists.

> Looking at the rest, it looks like some elf bits got exported, you added some
> more and that ship has sailed.

"some elf bits got exported" undersells it a bit. There are 14 years of dozens
of people adding constants to include/uapi/linux/elf.h. So far it doesn't seem
to have been a problem.

> I still think us providing headers is completely unnecessary and it will come
> to cause conflicts eventually but hey, not my problem.

As there is pushback, I'll just drop all of the header changes.
Maybe somebody else wants to deal with it at some point. Not my problem either.


Thomas