ELF auxiliary vector tags

[John Baldwin]

Currently, each architecture defines a list of auxiliary vector tag values (AT_*)
in the respective <machine/elf.h>. Most of these lists are identical except that
powerpc is missing AT_GID and AT_EGID and all the of the vectors after those two
are thus N-2 on powerpc compared to all our other architectures.

I noticed this while working on patches to add AT_HWCAP for ARM which debuggers
can use to determine the layout of VFP registers (and which might have other
uses at runtime).

I'd like to move AT_* to sys/elf_common.h to have a single list across all
platforms (the auxv parsing code in GDB for FreeBSD already assumes the list of
AT_* values is identical across all platforms on FreeBSD). However, it would be
convenient it powerpc could be updated to use the same values as all other
platforms. This would probably be a flag day for powerpc (breaking all existing
binaries) if we did it though, so I'm not sure if we can do that? I know Justin
changed time_t to 64-bit on 32-bit powerpc which effectively broke 32-bit
powerpc earlier, but this change would break both 32-bit and 64-bit powerpc and
is probably more disruptive (in theory some binaries might have worked with a
wrong time_t, but renumber AT_STACKPROT, etc. will probably break every binary).

Does anyone object to making AT_* MI, and if not, can we "break" powerpc or do
we need to preserve the AT_* values on powerpc?

[Konstantin Belousov]

Post by John Baldwin
Currently, each architecture defines a list of auxiliary vector tag values (AT_*)
in the respective <machine/elf.h>. Most of these lists are identical except that
powerpc is missing AT_GID and AT_EGID and all the of the vectors after those two
are thus N-2 on powerpc compared to all our other architectures.
I noticed this while working on patches to add AT_HWCAP for ARM which debuggers
can use to determine the layout of VFP registers (and which might have other
uses at runtime).
I'd like to move AT_* to sys/elf_common.h to have a single list across all
platforms (the auxv parsing code in GDB for FreeBSD already assumes the list of
AT_* values is identical across all platforms on FreeBSD). However, it would be
convenient it powerpc could be updated to use the same values as all other
platforms. This would probably be a flag day for powerpc (breaking all existing
binaries) if we did it though, so I'm not sure if we can do that? I know Justin
changed time_t to 64-bit on 32-bit powerpc which effectively broke 32-bit
powerpc earlier, but this change would break both 32-bit and 64-bit powerpc and
is probably more disruptive (in theory some binaries might have worked with a
wrong time_t, but renumber AT_STACKPROT, etc. will probably break every binary).

I added most if not all new AT_XXX constants. My impression from reading
the mess of existing ELF standards, updates and mailing lists is that
all the constants are considered as MD. Our AT_XXX values definitely do
not match other systems values, so if we start considering them MI, it
would be our own duty to maintain.

I do not object against it. The only consequence right now would be
that some values which are not needed on arches to become universally
allocated and eating some space in consumers (look for AT_COUNT and esp.
at the rtld.c:_rtld()).

Post by John Baldwin
Does anyone object to making AT_* MI, and if not, can we "break" powerpc or do
we need to preserve the AT_* values on powerpc?

It will be clear and serious ABI breakage on PPC, old ld-elf.so, libc and
static binaries stop working. Probably, the breakage would be not in
the form of segfaulting but rather a weird runtime behaviour. But if
PPC maintainers do not care, why not ?

[Warner Losh]

Post by John Baldwin

Post by John Baldwin
Currently, each architecture defines a list of auxiliary vector tag

values (AT_*)

Post by John Baldwin
in the respective <machine/elf.h>. Most of these lists are identical

except that

Post by John Baldwin
powerpc is missing AT_GID and AT_EGID and all the of the vectors after

those two

Post by John Baldwin
are thus N-2 on powerpc compared to all our other architectures.
I noticed this while working on patches to add AT_HWCAP for ARM which

debuggers

Post by John Baldwin
can use to determine the layout of VFP registers (and which might have

other

Post by John Baldwin
uses at runtime).
I'd like to move AT_* to sys/elf_common.h to have a single list across

all

Post by John Baldwin
platforms (the auxv parsing code in GDB for FreeBSD already assumes the

list of

Post by John Baldwin
AT_* values is identical across all platforms on FreeBSD). However, it

would be

Post by John Baldwin
convenient it powerpc could be updated to use the same values as all

other

Post by John Baldwin
platforms. This would probably be a flag day for powerpc (breaking all

existing

Post by John Baldwin
binaries) if we did it though, so I'm not sure if we can do that? I

know Justin

Post by John Baldwin
changed time_t to 64-bit on 32-bit powerpc which effectively broke 32-bit
powerpc earlier, but this change would break both 32-bit and 64-bit

powerpc and

Post by John Baldwin
is probably more disruptive (in theory some binaries might have worked

with a

Post by John Baldwin
wrong time_t, but renumber AT_STACKPROT, etc. will probably break every

binary).
I added most if not all new AT_XXX constants. My impression from reading
the mess of existing ELF standards, updates and mailing lists is that
all the constants are considered as MD. Our AT_XXX values definitely do
not match other systems values, so if we start considering them MI, it
would be our own duty to maintain.
I do not object against it. The only consequence right now would be
that some values which are not needed on arches to become universally
allocated and eating some space in consumers (look for AT_COUNT and esp.
at the rtld.c:_rtld()).

I generally think it is a good idea. There's a few caveats though.

PowerPC has a bunch of values that are different, though.

If AT_COUNT was significantly different, I'd be inclined to make
exceptions. However, it looks to be almost the same on them all...

Post by John Baldwin
Does anyone object to making AT_* MI, and if not, can we "break" powerpc or do

Post by John Baldwin
we need to preserve the AT_* values on powerpc?

It will be clear and serious ABI breakage on PPC, old ld-elf.so, libc and
static binaries stop working. Probably, the breakage would be not in
the form of segfaulting but rather a weird runtime behaviour. But if
PPC maintainers do not care, why not ?

I'm inclined to fall the other way. I'm inclined to have MI things for
everything, except PowerPC. Since this breaks all binaries, it also breaks
all upgrade paths, so I'd be quite leery of doing it. Sure, there's some
wide-scale breakages, but I'd be inclined to make it be an exception since
a small wart there sure beats a flag day that's even more severe than the
time_t breakage. On the other hand, a clear message in UPDATING and the
'tier 2' card wouldn't be horrible here.

Warner

[Julian Elischer]

Post by John Baldwin
Currently, each architecture defines a list of auxiliary vector tag values (AT_*)
in the respective <machine/elf.h>. Most of these lists are identical except that
powerpc is missing AT_GID and AT_EGID and all the of the vectors after those two
are thus N-2 on powerpc compared to all our other architectures.
I noticed this while working on patches to add AT_HWCAP for ARM which debuggers
can use to determine the layout of VFP registers (and which might have other
uses at runtime).
I'd like to move AT_* to sys/elf_common.h to have a single list across all
platforms (the auxv parsing code in GDB for FreeBSD already assumes the list of
AT_* values is identical across all platforms on FreeBSD). However, it would be
convenient it powerpc could be updated to use the same values as all other
platforms. This would probably be a flag day for powerpc (breaking all existing
binaries) if we did it though, so I'm not sure if we can do that? I know Justin
changed time_t to 64-bit on 32-bit powerpc which effectively broke 32-bit
powerpc earlier, but this change would break both 32-bit and 64-bit powerpc and
is probably more disruptive (in theory some binaries might have worked with a
wrong time_t, but renumber AT_STACKPROT, etc. will probably break every binary).
Does anyone object to making AT_* MI, and if not, can we "break" powerpc or do
we need to preserve the AT_* values on powerpc?

I'm guessing it would require a 2 or 3 step process over quite a long
time period.

An alias for each of the entries about the one s you mention, while
still supporting the ones in old binaries
and then after a couple of years removing the originals, and then
after a couple of
years more, moving them to the new locations (with maybe some cookie
change to declare old binaries unrunable

or maybe something as radical a separate image executor.

[Marcel Moolenaar]

I know Justin changed time_t to 64-bit on 32-bit powerpc which effectively broke 32-bit powerpc earlier, but this change would break both 32-bit and 64-bit powerpc and is probably more disruptive (in theory some binaries might have worked with a wrong time_t, but renumber AT_STACKPROT, etc. will probably break every binary).

That probably depends on the byte order. I would think widening
time_t on a big-endian machine is a lot more disruptive than
doing it on a little-endian machine.

That said and along the lines of what @imp said:
Maybe add a a MD macro (e.g. NO_MI_AUX_VECTORS) whose existence
suppresses the MI definitions of AT_* so that MD headers can
define their own?

[John Baldwin]

Post by Marcel Moolenaar

I know Justin changed time_t to 64-bit on 32-bit powerpc which effectively broke 32-bit powerpc earlier, but this change would break both 32-bit and 64-bit powerpc and is probably more disruptive (in theory some binaries might have worked with a wrong time_t, but renumber AT_STACKPROT, etc. will probably break every binary).

That probably depends on the byte order. I would think widening
time_t on a big-endian machine is a lot more disruptive than
doing it on a little-endian machine.
Maybe add a a MD macro (e.g. NO_MI_AUX_VECTORS) whose existence
suppresses the MI definitions of AT_* so that MD headers can
define their own?

Going forward I would like to standardize on common values for new vectors
added. The current implementation of 'info auxv' for GDB assumes they
are the same on all architectures (and judging by the binutils / gdb bits
for Linux, Linux uses the same AT_* values on all platforms). Are you
running powerpc binaries yourself? The only person who I know is who has
replied (Justin) is fine with just pulling the tier-2 card on powerpc to
bring it inline with all the other platforms (which are already identical).

One suggestion was to set a value in AT_FLAGS (currently always set to zero)
that binaries could then use to detect the new layout on ppc.

[Warner Losh]

Post by Marcel Moolenaar

I know Justin changed time_t to 64-bit on 32-bit powerpc which

effectively broke 32-bit powerpc earlier, but this change would break both
32-bit and 64-bit powerpc and is probably more disruptive (in theory some
binaries might have worked with a wrong time_t, but renumber AT_STACKPROT,
etc. will probably break every binary).

Post by Marcel Moolenaar
That probably depends on the byte order. I would think widening
time_t on a big-endian machine is a lot more disruptive than
doing it on a little-endian machine.
Maybe add a a MD macro (e.g. NO_MI_AUX_VECTORS) whose existence
suppresses the MI definitions of AT_* so that MD headers can
define their own?

Going forward I would like to standardize on common values for new vectors
added. The current implementation of 'info auxv' for GDB assumes they
are the same on all architectures (and judging by the binutils / gdb bits
for Linux, Linux uses the same AT_* values on all platforms). Are you
running powerpc binaries yourself? The only person who I know is who has
replied (Justin) is fine with just pulling the tier-2 card on powerpc to
bring it inline with all the other platforms (which are already identical).

I think aligning is the right thing, regardless of tier status. The
question about 'adding compat' is a separate issue, imho.

One suggestion was to set a value in AT_FLAGS (currently always set to zero)
that binaries could then use to detect the new layout on ppc.

This is a path forward if we want to maintain upgradability across this
incident. I don't think it's incumbent on John to do it (unless he wants
to). It's incumbent on the powerpc folks if they need the compatibility. If
this were arm the calculous would be different (since lots of people do
binary upgrades and it's de-facto nearly tier 1) or even mips (where some
people do binary upgrades, despite being definitely not tier 1). OTOH, if
John did this to arm and didn't do compat shims, myself or some other arm
user would do them. The only question would be how much snark would make
its way into the commit message :) It's also a reasonable fallback plan
should more users than just Justin be affected given the bumpy nature of
-current at time.

Warner

[Nathan Whitehorn]

Post by Warner Losh

Post by Marcel Moolenaar

I know Justin changed time_t to 64-bit on 32-bit powerpc which

effectively broke 32-bit powerpc earlier, but this change would break both
32-bit and 64-bit powerpc and is probably more disruptive (in theory some
binaries might have worked with a wrong time_t, but renumber AT_STACKPROT,
etc. will probably break every binary).

Post by Marcel Moolenaar
That probably depends on the byte order. I would think widening
time_t on a big-endian machine is a lot more disruptive than
doing it on a little-endian machine.
Maybe add a a MD macro (e.g. NO_MI_AUX_VECTORS) whose existence
suppresses the MI definitions of AT_* so that MD headers can
define their own?

Going forward I would like to standardize on common values for new vectors
added. The current implementation of 'info auxv' for GDB assumes they
are the same on all architectures (and judging by the binutils / gdb bits
for Linux, Linux uses the same AT_* values on all platforms). Are you
running powerpc binaries yourself? The only person who I know is who has
replied (Justin) is fine with just pulling the tier-2 card on powerpc to
bring it inline with all the other platforms (which are already identical).

I think aligning is the right thing, regardless of tier status. The
question about 'adding compat' is a separate issue, imho.

One suggestion was to set a value in AT_FLAGS (currently always set to zero)
that binaries could then use to detect the new layout on ppc.

This is a path forward if we want to maintain upgradability across this
incident. I don't think it's incumbent on John to do it (unless he wants
to). It's incumbent on the powerpc folks if they need the compatibility. If
this were arm the calculous would be different (since lots of people do
binary upgrades and it's de-facto nearly tier 1) or even mips (where some
people do binary upgrades, despite being definitely not tier 1). OTOH, if
John did this to arm and didn't do compat shims, myself or some other arm
user would do them. The only question would be how much snark would make
its way into the commit message :) It's also a reasonable fallback plan
should more users than just Justin be affected given the bumpy nature of
-current at time.

We just broke PPC compatibility anyway, so this seems like the perfect
time to push forward and not worry about compat.
-Nathan

[Marcel Moolenaar]

Are you running powerpc binaries yourself?

No, not anymore.

The only person who I know is who has replied (Justin) is fine with just pulling the tier-2 card on powerpc to bring it inline with all the other platforms (which are already identical).

I think you’re good to go with the unification then!

[Mark Linimon]

Post by Marcel Moolenaar

Are you running powerpc binaries yourself?

No, not anymore.

I run them but will do the work.

You need to talk to swills@ as well.

mcl

[Andreas Tobler]

Post by John Baldwin

Post by Marcel Moolenaar

I know Justin changed time_t to 64-bit on 32-bit powerpc which effectively broke 32-bit powerpc earlier, but this change would break both 32-bit and 64-bit powerpc and is probably more disruptive (in theory some binaries might have worked with a wrong time_t, but renumber AT_STACKPROT, etc. will probably break every binary).

That probably depends on the byte order. I would think widening
time_t on a big-endian machine is a lot more disruptive than
doing it on a little-endian machine.
Maybe add a a MD macro (e.g. NO_MI_AUX_VECTORS) whose existence
suppresses the MI definitions of AT_* so that MD headers can
define their own?

Going forward I would like to standardize on common values for new vectors
added. The current implementation of 'info auxv' for GDB assumes they
are the same on all architectures (and judging by the binutils / gdb bits
for Linux, Linux uses the same AT_* values on all platforms). Are you
running powerpc binaries yourself? The only person who I know is who has
replied (Justin) is fine with just pulling the tier-2 card on powerpc to
bring it inline with all the other platforms (which are already identical).

+1 from my side.

Andreas