ELF auxiliary vector tags

[Nathan Whitehorn]

On 09/12/17 08:43, Warner Losh wrote:
> On Mon, Sep 11, 2017 at 4:45 PM, John Baldwin <jhb at 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 at 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