From owner-freebsd-arch@freebsd.org Fri Sep 8 21:13:37 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 351F4E0B141 for ; Fri, 8 Sep 2017 21:13:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0FD3B6B0ED for ; Fri, 8 Sep 2017 21:13:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0F1B4E0B140; Fri, 8 Sep 2017 21:13:37 +0000 (UTC) Delivered-To: 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 0EBC7E0B13F for ; Fri, 8 Sep 2017 21:13:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC8FB6B0EB for ; Fri, 8 Sep 2017 21:13:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id n69so7048425ioi.5 for ; Fri, 08 Sep 2017 14:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=g0VFRXYdiKm9MDibIirWXuutMZJqtxHbG53oGwRQtLc=; b=1AQxdL42wsNPqHRl736jRIeeXe9DXQtU9IFenbZLTc1Y6B6S1mHUPd4NcAxaoDCEAq wvxjCQPbtg5j7kfaRicC6kRtw5nSjJPogIrCyUavc22qPmT48JlfkWlQ6v/FUTEY0M0i +mRpzw5SA+Gzf2SKu4sH0vi29YIodbbstCUVH7KW4Lr/ffBTbtZljM9pyZNgV2xl5ruk uJUnEfSOGNr8TFj3o4B/tvnDG6lNWNhsyl8EwlNEn3GYj0WqnTQkKoPvZUVptNAUgRqN /67nqK+uizkp9qF18zfhJc6faUE2/yQZAcveD0tsDK2r+ae7K3qhfXC2a/yA+PKirPnJ 6suQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=g0VFRXYdiKm9MDibIirWXuutMZJqtxHbG53oGwRQtLc=; b=AI64cs1hQrBFD/cG+cTmmdPVTGkghhuP+alxUeYx+IWwHgIC52GYzZ2qoPhOKrgHwi SyXOmYNCrG/SjHbhitmdl4j3tnUGok+bSLYoM9CBYH+ClhAOG/cyd+KnbA6uuWMZxTxv pmfwW9TElWS9n4v1rkltlJ/rR5eULzt3Yg5NhCVvhqUAdqUbj76XCccZUiWsAoTTv7aH Ue8vc4ieDztdei+jwKLBai+Fph2c/HHJEO3PADM02PiKi3gcO0AO40HaroXtQq+Uk+5f V2JN/GjewL6maYghvK5v4dNZfxjgLYrjFwDjix3ROtwc39qiB9jg2wDU0kAtgfVR9OC3 2JZg== X-Gm-Message-State: AHPjjUibnmwViy/6WC/RxsAjbh1+tPOwNcYCt+7Akn3n2mZO93mz/QFh J6g5lkdsWQ10CUoU+T6TRBHDOQ4e2STE X-Google-Smtp-Source: AOwi7QDl6QcY4BeODcIEoCxfZd3mUn40McDiGl0gyXecRPPZghUzomS5+3qbDg0PED84bJ5eM4wTLbRx1Oa6wKgiCtQ= X-Received: by 10.107.142.83 with SMTP id q80mr5034090iod.208.1504905216120; Fri, 08 Sep 2017 14:13:36 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Fri, 8 Sep 2017 14:13:35 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20170908180422.GO1700@kib.kiev.ua> References: <20170908180422.GO1700@kib.kiev.ua> From: Warner Losh Date: Fri, 8 Sep 2017 15:13:35 -0600 X-Google-Sender-Auth: XlsDcVsh6JRD6MYB-b5qQp-Vb6Y Message-ID: Subject: Re: ELF auxiliary vector tags To: Konstantin Belousov Cc: John Baldwin , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Fri, 08 Sep 2017 21:13:37 -0000 On Fri, Sep 8, 2017 at 12:04 PM, Konstantin Belousov 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 . 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