[PATCH] Introduce biarch DISTRO_FEATURE

[PATCH] Introduce biarch DISTRO_FEATURE

[Julian Pidancet]

This patch introduces a distro feature which enables gcc to produce
both 32bit and 64bit code, and enables binutils to operate on both
32bit and 64bit binaries. It differs from multilib toolchains in
that it does not require to compile a version of the libc for each
architecture variant. However, the code produced for the secondary
architecture will not be linkable against the libc.

This patch only works with x86 and x86_64 architectures, but can
probably be extended to support other architectures as well.

One use-case would be when one wants to compile a system which runs
32bit userspace applications with a 64bit kernel without having to
deal with two separate libc.

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 meta/recipes-devtools/binutils/binutils-cross.inc  |    3 ++-
 meta/recipes-devtools/binutils/binutils.inc        |    3 ++-
 meta/recipes-devtools/gcc/gcc-common.inc           |    5 +++++
 meta/recipes-devtools/gcc/gcc-configure-common.inc |    3 ++-
 4 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/binutils/binutils-cross.inc b/meta/recipes-devtools/binutils/binutils-cross.inc
index 982224f..3f76c59 100644
--- a/meta/recipes-devtools/binutils/binutils-cross.inc
+++ b/meta/recipes-devtools/binutils/binutils-cross.inc
@@ -10,7 +10,8 @@ EXTRA_OECONF = "--with-sysroot=${STAGING_DIR_TARGET} \
                 --disable-werror \
                 --disable-nls \
                 --enable-poison-system-directories \
-		${@base_contains('DISTRO_FEATURES', 'ld-is-gold', '--enable-gold=default', '', d)}"
+                ${@base_contains('DISTRO_FEATURES', 'ld-is-gold', '--enable-gold=default', '', d)} \
+                ${@base_contains('DISTRO_FEATURES', 'biarch', '--enable-64-bit-bfd', '', d)}"
 
 do_install () {
 	oe_runmake 'DESTDIR=${D}' install
diff --git a/meta/recipes-devtools/binutils/binutils.inc b/meta/recipes-devtools/binutils/binutils.inc
index 58fee85..fe16b18 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -49,7 +49,8 @@ B = "${S}/build.${HOST_SYS}.${TARGET_SYS}"
 
 EXTRA_OECONF = "--program-prefix=${TARGET_PREFIX} \
                 --enable-install-libbfd \
-                --enable-shared"
+                --enable-shared \
+                ${@base_contains('DISTRO_FEATURES', 'biarch', '--enable-64-bit-bfd', '', d)}"
 
 EXTRA_OECONF_virtclass-native = "--enable-target=all --enable-64-bit-bfd --enable-install-libbfd"
 
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
index f83f4da..fdbb77b 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -21,6 +21,11 @@ def get_gcc_mips_plt_setting(bb, d):
         return "--with-mips-plt"
     return ""
 
+def get_gcc_x86_biarch_setting(bb, d):
+    if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'i586', 'i686', 'x86_64' ] and 'biarch' in bb.data.getVar('DISTRO_FEATURES',d,1).split() :
+        return "--enable-targets=all"
+    return ""
+
 # We really need HOST_SYS here for some packages and TARGET_SYS for others.
 # For now, libgcc is most important so we fix for that - RP.
 SHLIBSDIR = "${STAGING_DIR_TARGET}/shlibs"
diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc b/meta/recipes-devtools/gcc/gcc-configure-common.inc
index 2ddc3d7..55a0626 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
@@ -42,7 +42,8 @@ EXTRA_OECONF = "${@['--enable-clocale=generic', ''][bb.data.getVar('USE_NLS', d,
                 ${EXTRA_OECONF_BASE} \
                 ${EXTRA_OECONF_FPU} \
                 ${EXTRA_OECONF_PATHS} \
-                ${@get_gcc_mips_plt_setting(bb, d)}"
+                ${@get_gcc_mips_plt_setting(bb, d)} \
+                ${@get_gcc_x86_biarch_setting(bb, d)}"
 
 # Build uclibc compilers without cxa_atexit support
 EXTRA_OECONF_append_linux               = " --enable-__cxa_atexit"
-- 
Julian Pidancet

Re: [PATCH] Introduce biarch DISTRO_FEATURE

[McClintock Matthew-B29882]

On Mon, Oct 24, 2011 at 8:18 PM, Julian Pidancet
<julian.pidancet@gmail.com> wrote:
> This patch introduces a distro feature which enables gcc to produce
> both 32bit and 64bit code, and enables binutils to operate on both
> 32bit and 64bit binaries. It differs from multilib toolchains in
> that it does not require to compile a version of the libc for each
> architecture variant. However, the code produced for the secondary
> architecture will not be linkable against the libc.
>
> This patch only works with x86 and x86_64 architectures, but can
> probably be extended to support other architectures as well.
>
> One use-case would be when one wants to compile a system which runs
> 32bit userspace applications with a 64bit kernel without having to
> deal with two separate libc.

What happens with the native gcc on the root file system. And what
about meta-toolchain? Any effect?

Thanks,
Matthew

Re: [PATCH] Introduce biarch DISTRO_FEATURE

[Julian Pidancet]

On Wed, Oct 26, 2011 at 3:09 AM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Mon, Oct 24, 2011 at 8:18 PM, Julian Pidancet
> <julian.pidancet@gmail.com> wrote:
>> This patch introduces a distro feature which enables gcc to produce
>> both 32bit and 64bit code, and enables binutils to operate on both
>> 32bit and 64bit binaries. It differs from multilib toolchains in
>> that it does not require to compile a version of the libc for each
>> architecture variant. However, the code produced for the secondary
>> architecture will not be linkable against the libc.
>>
>> This patch only works with x86 and x86_64 architectures, but can
>> probably be extended to support other architectures as well.
>>
>> One use-case would be when one wants to compile a system which runs
>> 32bit userspace applications with a 64bit kernel without having to
>> deal with two separate libc.
>
> What happens with the native gcc on the root file system. And what
> about meta-toolchain? Any effect?
>

Hi Matthew, sorry for the late answer.

I'm affraid I don't quite see what you mean by "the native gcc on the
root file system". Are you refering to the version of GCC present on
the build machine and built by OE ? Or are you refering instead about
a potential version of GCC running on the target ?

This patch should only make gcc-cross, and gcc running on the target
"biarch". It would also probably make sense to build a biarch GCC in
the meta-toolchain case.

To be honest, I have not really considered the meta-toolchain case as
I've never used it before and not quite sure how it works.

I can respin a patch to handle the meta-toolchain case. But in the
mean-time, it would be nice if I could get an opinion on wether this
"biarch" feature is a good idea or not, or, if not, maybe some
suggestions about how to address this specific 32bit/64bit use-case
differently.

-- 
Julian

Re: [PATCH] Introduce biarch DISTRO_FEATURE

[McClintock Matthew-B29882]

On Mon, Nov 7, 2011 at 5:14 PM, Julian Pidancet
<julian.pidancet@gmail.com> wrote:
> Hi Matthew, sorry for the late answer.
>
> I'm affraid I don't quite see what you mean by "the native gcc on the
> root file system". Are you refering to the version of GCC present on
> the build machine and built by OE ? Or are you refering instead about
> a potential version of GCC running on the target ?
>
> This patch should only make gcc-cross, and gcc running on the target
> "biarch". It would also probably make sense to build a biarch GCC in
> the meta-toolchain case.

This is what I was referring too... cross gcc in /opt/poky/ that can
build for multiple targets...

> To be honest, I have not really considered the meta-toolchain case as
> I've never used it before and not quite sure how it works.

It just builds an installable tarball with the toolchain components
and some other nativesdk components.

> I can respin a patch to handle the meta-toolchain case. But in the
> mean-time, it would be nice if I could get an opinion on wether this
> "biarch" feature is a good idea or not, or, if not, maybe some
> suggestions about how to address this specific 32bit/64bit use-case
> differently.

Can't really comment on your patch... but I know it would be nice to
generate a cross gcc that supports more than just the target yocto is
building for at the time. For instance, build support for all powerpc
or all x86 targets poky could possibly build for when building
meta-toolchain....

-M

Re: [PATCH] Introduce biarch DISTRO_FEATURE

[Richard Purdie]

On Mon, 2011-11-07 at 23:14 +0000, Julian Pidancet wrote:
> On Wed, Oct 26, 2011 at 3:09 AM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
> > On Mon, Oct 24, 2011 at 8:18 PM, Julian Pidancet
> > <julian.pidancet@gmail.com> wrote:
> >> This patch introduces a distro feature which enables gcc to produce
> >> both 32bit and 64bit code, and enables binutils to operate on both
> >> 32bit and 64bit binaries. It differs from multilib toolchains in
> >> that it does not require to compile a version of the libc for each
> >> architecture variant. However, the code produced for the secondary
> >> architecture will not be linkable against the libc.
> >>
> >> This patch only works with x86 and x86_64 architectures, but can
> >> probably be extended to support other architectures as well.
> >>
> >> One use-case would be when one wants to compile a system which runs
> >> 32bit userspace applications with a 64bit kernel without having to
> >> deal with two separate libc.
> >
> > What happens with the native gcc on the root file system. And what
> > about meta-toolchain? Any effect?
> >
> 
> Hi Matthew, sorry for the late answer.
> 
> I'm affraid I don't quite see what you mean by "the native gcc on the
> root file system". Are you refering to the version of GCC present on
> the build machine and built by OE ? Or are you refering instead about
> a potential version of GCC running on the target ?
> 
> This patch should only make gcc-cross, and gcc running on the target
> "biarch". It would also probably make sense to build a biarch GCC in
> the meta-toolchain case.
> 
> To be honest, I have not really considered the meta-toolchain case as
> I've never used it before and not quite sure how it works.
> 
> I can respin a patch to handle the meta-toolchain case. But in the
> mean-time, it would be nice if I could get an opinion on wether this
> "biarch" feature is a good idea or not, or, if not, maybe some
> suggestions about how to address this specific 32bit/64bit use-case
> differently.

I'm left wondering how useful the resulting compiler is to most users.
In most cases a user would expect full libc support and hence this is
likely to confuse them. I do appreciate people do have usecases for a
compiler that can handle the other bit format though.

I think my biggest worry is the "--enable-targets=all" option which may
or may not enable things we might not want enabled. I've not had a
chance to go and look at gcc and convince myself that piece is safe. The
other pieces looked less worrying.

Cheers,

Richard

Re: [PATCH] Introduce biarch DISTRO_FEATURE

[Julian Pidancet]

On 11/08/11 20:29, Richard Purdie wrote:
> 
> I'm left wondering how useful the resulting compiler is to most users.
> In most cases a user would expect full libc support and hence this is
> likely to confuse them. I do appreciate people do have usecases for a
> compiler that can handle the other bit format though.
> 

Standard linux distros out there like debian or gentoo already ship a
biarch gcc per default. It wouldn't seem odd to me if OE had an option
to enable the generation of a biarch compiler.

> I think my biggest worry is the "--enable-targets=all" option which may
> or may not enable things we might not want enabled. I've not had a
> chance to go and look at gcc and convince myself that piece is safe. The
> other pieces looked less worrying.
> 

In the patch, the --enable-targets=all is only active in the x86 case. I
did not find any other way of enabling both -m32 and -m64 switches in gcc.

I've been successfully using this patch to generate a complete x86 32bit
distro with a 64bit Xen hypervisor (I believe the result would have been
the same if I tried to compile a 64bit linux kernel). I did not have any
issues with it so far.

Cheers,

-- 
Julian

Re: [PATCH] Introduce biarch DISTRO_FEATURE

[Khem Raj]

On Thu, Nov 10, 2011 at 5:43 AM, Julian Pidancet
<julian.pidancet@gmail.com> wrote:
> On 11/08/11 20:29, Richard Purdie wrote:
>>
>> I'm left wondering how useful the resulting compiler is to most users.
>> In most cases a user would expect full libc support and hence this is
>> likely to confuse them. I do appreciate people do have usecases for a
>> compiler that can handle the other bit format though.
>>
>
> Standard linux distros out there like debian or gentoo already ship a
> biarch gcc per default. It wouldn't seem odd to me if OE had an option
> to enable the generation of a biarch compiler.
>
>> I think my biggest worry is the "--enable-targets=all" option which may
>> or may not enable things we might not want enabled. I've not had a
>> chance to go and look at gcc and convince myself that piece is safe. The
>> other pieces looked less worrying.
>>
>
> In the patch, the --enable-targets=all is only active in the x86 case. I
> did not find any other way of enabling both -m32 and -m64 switches in gcc.

enable-target=all would sort of create a single toolchain for multlibs we have
but it needs to package the gcc runtime and building glibc accordingly
I cant say
it will be just harmless to enable it right now mips/powerpc/x86 are
architectures
that could do it in oe.

>
> I've been successfully using this patch to generate a complete x86 32bit
> distro with a 64bit Xen hypervisor (I believe the result would have been
> the same if I tried to compile a 64bit linux kernel). I did not have any
> issues with it so far.
>
> Cheers,
>
> --
> Julian
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>