From owner-freebsd-arch@freebsd.org Wed Sep 13 05:23:29 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01420E0CD23 for ; Wed, 13 Sep 2017 05:23:29 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D47DB734BA for ; Wed, 13 Sep 2017 05:23:28 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (cpe-45-48-160-106.socal.res.rr.com [45.48.160.106]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v8D5BXPB026869 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 12 Sep 2017 22:11:33 -0700 Subject: Re: ELF auxiliary vector tags To: freebsd-arch@freebsd.org References: <26458208-EC4B-4647-8271-DF480EDD57DF@xcllnt.net> <5184520.CTdkFHEYDQ@ralph.baldwin.cx> From: Nathan Whitehorn Message-ID: <565a4072-f95d-3d2e-1405-7bfc0286120b@freebsd.org> Date: Tue, 12 Sep 2017 22:11:33 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVZsp7BpRFEetMBFxqJ7f1fnreMVI69N5mhYHfdkLhrNyWJlC6R4lQA93NF1A6CwIDKVX1AhuVzkOe7Oe2Cm1bjk9UJRkL61vTQ= X-Sonic-ID: C;SPVvAkKY5xGBqcGbEi49jA== M;vpm+AkKY5xGBqcGbEi49jA== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 05:23:29 -0000 On 09/12/17 08:43, Warner Losh wrote: > On Mon, Sep 11, 2017 at 4:45 PM, John Baldwin wrote: > >> On Monday, September 11, 2017 12:05:02 PM Marcel Moolenaar wrote: >>>> On Sep 8, 2017, at 10:36 AM, John Baldwin 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