Date: Sun, 10 Sep 2017 00:18:20 +0800 From: Julian Elischer <julian@freebsd.org> To: John Baldwin <jhb@FreeBSD.org>, arch@freebsd.org Subject: Re: ELF auxiliary vector tags Message-ID: <6a29f889-016e-5a72-4124-7c58b605cf6c@freebsd.org> In-Reply-To: <ecca895d-2553-f2bf-4a44-5e379c07a9d4@FreeBSD.org> References: <ecca895d-2553-f2bf-4a44-5e379c07a9d4@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/9/17 1:36 am, John Baldwin wrote: > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6a29f889-016e-5a72-4124-7c58b605cf6c>