Date: Fri, 8 Sep 2017 21:04:22 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@freebsd.org Subject: Re: ELF auxiliary vector tags Message-ID: <20170908180422.GO1700@kib.kiev.ua> 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 Fri, Sep 08, 2017 at 01:36:52PM -0400, 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). 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()). > > 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 ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170908180422.GO1700>