From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3tPw8q1B04zDw7h for ; Fri, 25 Nov 2016 10:17:30 +1100 (AEDT) Date: Thu, 24 Nov 2016 17:17:16 -0600 From: Segher Boessenkool To: Michael Ellerman Cc: "Oliver O'Halloran" , linuxppc-dev@lists.ozlabs.org, Nicholas Piggin , Alan Modra Subject: Re: [RFC][PATCH] powerpc/64be: use ELFv2 ABI for big endian kernels Message-ID: <20161124231716.GB30675@gate.crashing.org> References: <20161123130840.1877-1-npiggin@gmail.com> <20161123143834.GB6099@gate.crashing.org> <20161124122713.GC14394@gate.crashing.org> <87d1hktt5z.fsf@concordia.ellerman.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <87d1hktt5z.fsf@concordia.ellerman.id.au> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Nov 25, 2016 at 09:22:16AM +1100, Michael Ellerman wrote: > >> >> Question, are there any fundamental reasons we shouldn't use the ELFv2 > >> >> ABI to build big endian kernels if the compiler supports it? > >> > > >> > No one uses ELFv2 for BE in production, and it isn't thoroughly tested > >> > at all, not even regularly tested. "Not supported", as far as GCC is > >> > concerned (or any of the distros AFAIK). > >> > >> Is this actually unsupported by gcc? > > > > It may or may not work. We of course try to keep it working, or make > > it work if it doesn't now. But it isn't regularly tested, and it isn't > > a target that is considered for the release criteria (see > > https://gcc.gnu.org/gcc-7/criteria.html -- powerpc64{,le}-linux, i.e. > > ABIv1 for BE, ABIv2 for LE). > > It doesn't actually say that though. It just says > powerpc64-unknown-linux-gnu. So how is someone, say the musl folks, > supposed to know that BE ABIv2 is not supported? Because their target is powerpc64*-*-linux-musl instead? It is not on the release criteria list, it is not something we make any claims about. How would you know -m32 -mlittle is not well tested at all? It is in much the same boat: unusual combinations of options, and unusual configurations, are not well tested. You have to build a separate C library just to get started with it, that should tell you there are some rough waters ahead! Which isn't to say you should not do this -- just think twice before doing so. And wear a life vest. Segher