Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Sep 2017 09:43:04 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Marcel Moolenaar <marcel@xcllnt.net>, "freebsd-arch@freebsd.org" <arch@freebsd.org>
Subject:   Re: ELF auxiliary vector tags
Message-ID:  <CANCZdfq5nB%2ByyvT3SJ9FVPRRG570c7hs5QU3AO=itSWr1j8cZw@mail.gmail.com>
In-Reply-To: <5184520.CTdkFHEYDQ@ralph.baldwin.cx>
References:  <ecca895d-2553-f2bf-4a44-5e379c07a9d4@FreeBSD.org> <26458208-EC4B-4647-8271-DF480EDD57DF@xcllnt.net> <5184520.CTdkFHEYDQ@ralph.baldwin.cx>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq5nB%2ByyvT3SJ9FVPRRG570c7hs5QU3AO=itSWr1j8cZw>