Date: Fri, 8 Sep 2017 15:13:35 -0600 From: Warner Losh <imp@bsdimp.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: John Baldwin <jhb@freebsd.org>, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: ELF auxiliary vector tags Message-ID: <CANCZdfq2ZoZ_wwGdOyKgT3y_=z%2BYq5h5snY5uTRRHiti0f6rYg@mail.gmail.com> In-Reply-To: <20170908180422.GO1700@kib.kiev.ua> References: <ecca895d-2553-f2bf-4a44-5e379c07a9d4@FreeBSD.org> <20170908180422.GO1700@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 8, 2017 at 12:04 PM, Konstantin Belousov <kostikbel@gmail.com> wrote: > 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()). 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... > 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 ? 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq2ZoZ_wwGdOyKgT3y_=z%2BYq5h5snY5uTRRHiti0f6rYg>