From owner-freebsd-arch@freebsd.org Fri Sep 8 18:04:28 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 06362E01BFB for ; Fri, 8 Sep 2017 18:04:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E23FF64BDE for ; Fri, 8 Sep 2017 18:04:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id DE1B6E01BFA; Fri, 8 Sep 2017 18:04:27 +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 DDA09E01BF9 for ; Fri, 8 Sep 2017 18:04:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 727D364BDD; Fri, 8 Sep 2017 18:04:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v88I4MLt022664 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Sep 2017 21:04:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v88I4MLt022664 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v88I4M2U022663; Fri, 8 Sep 2017 21:04:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Sep 2017 21:04:22 +0300 From: Konstantin Belousov To: John Baldwin Cc: arch@freebsd.org Subject: Re: ELF auxiliary vector tags Message-ID: <20170908180422.GO1700@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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 18:04:28 -0000 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()). > > 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 ?