On Mon, 2018-12-17 at 11:36 +0200, Serhey Popovych wrote:
> Khem Raj wrote:
> > On Fri, Dec 14, 2018 at 9:56 AM Serhey Popovych
> > <serhe.popov...@gmail.com> wrote:
> > > Historically first PowerPC ABI was big-endian only (elfv1
> > > currently). It
> > > is standard ABI for both 32-bit ppc and 64-bit ppc64
> > > architectures.
> > >
> > > With PowerPC little-endian support new ABI was introduced (elfv2)
> > > and it
> > > is used primarily with ppc64le target only. While it has support
> > > for
> > > big-endian it is not commonly used and elfv1 still preferred.
> > >
> > > Musl does support only elfv2 ABI for both LE and BE and does not
> > > have
> > > any plans to support elfv1.
> > >
> > > Since then to build for powerpc64 with musl new ABI should be
> > > used. As
> > > expected it is not compatible with elfv1 but that isn't problem
> > > as long
> > > as there is no binary distributed software or assembly code
> > > written for
> > > elfv1 ABI.
> > >
> > > Signed-off-by: Serhey Popovych <serhe.popov...@gmail.com>
> > > ---
> > > meta/conf/machine/include/powerpc/arch-powerpc64.inc | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/meta/conf/machine/include/powerpc/arch-powerpc64.inc
> > > b/meta/conf/machine/include/powerpc/arch-powerpc64.inc
> > > index f751c6b..d9916d4 100644
> > > --- a/meta/conf/machine/include/powerpc/arch-powerpc64.inc
> > > +++ b/meta/conf/machine/include/powerpc/arch-powerpc64.inc
> > > @@ -7,6 +7,9 @@ TUNECONFLICTS[m64] = "m32 nf"
> > > TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'm64', '
> > > -m64', '', d)}"
> > > TUNE_ARCH .= "${@bb.utils.contains('TUNE_FEATURES', [ 'm64' ],
> > > 'powerpc64', '', d)}"
> > >
> > > +# musl only supports elfv2 ABI for ppc64
> > > +TUNE_CCARGS .= "${@['', ' -mabi=elfv2']['libc-musl' in
> > > d.getVar('OVERRIDES').split(':')]}"
> > > +
> >
> > I wonder if we should change gcc to use this ABI by default when
> > configured for ppc64/musl ?
> > This would avoid us adding compiler options here, in bad cases it
> > may
> > be that other compilers
> > call it out differently.
>
> Good point. This should be easy to do with patch applied for libc-
> musl
> override.
Given our gcc shared-workdir which is shared between musl and non-musl
builds, I'm not sure this will be quite that easy. It would need to be
build configuration time rather than source patching...
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
