Date: Tue, 12 Sep 2017 20:59:53 +0200 From: Andreas Tobler <andreast@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: ELF auxiliary vector tags Message-ID: <abb458f6-165c-75e0-ffd7-8e5c6fcdc486@FreeBSD.org> 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 12.09.17 00:45, 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 <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). +1 from my side. Andreas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?abb458f6-165c-75e0-ffd7-8e5c6fcdc486>