Date: Tue, 12 Sep 2017 22:11:33 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: freebsd-arch@freebsd.org Subject: Re: ELF auxiliary vector tags Message-ID: <565a4072-f95d-3d2e-1405-7bfc0286120b@freebsd.org> In-Reply-To: <CANCZdfq5nB%2ByyvT3SJ9FVPRRG570c7hs5QU3AO=itSWr1j8cZw@mail.gmail.com> References: <ecca895d-2553-f2bf-4a44-5e379c07a9d4@FreeBSD.org> <26458208-EC4B-4647-8271-DF480EDD57DF@xcllnt.net> <5184520.CTdkFHEYDQ@ralph.baldwin.cx> <CANCZdfq5nB%2ByyvT3SJ9FVPRRG570c7hs5QU3AO=itSWr1j8cZw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/12/17 08:43, Warner Losh wrote: > On Mon, Sep 11, 2017 at 4:45 PM, John Baldwin <jhb@freebsd.org> wrote: > >> On Monday, September 11, 2017 12:05:02 PM Marcel Moolenaar wrote: >>>> On Sep 8, 2017, at 10:36 AM, John Baldwin <jhb@freebsd.org> wrote: >>> >>>> 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? >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?565a4072-f95d-3d2e-1405-7bfc0286120b>