[Buildroot] Illegal instruction by python's xmlrpclib on powerpc64, gcc-4.9

[Buildroot] Illegal instruction by python's xmlrpclib on powerpc64, gcc-4.9

[Alvaro Gamez]

Hi there

I'm trying to use xmlrpclib module from python on this architecture,
but whenever I import that module I'm answered back with an 'Illegal
instruction':

Python 2.7.10 (default, Oct 29 2015, 11:03:21)
[GCC 4.9.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xmlrpclib
Illegal instruction

And this appears on dmesg:
python[1439]: unhandled signal 4 at 00003fffb19ec6dc nip 00003fffb19ec6dc
lr 00003fffb19ec6b0 code 30001

This doesn't happen when importing other modules, such as sys or os, but I
haven't tested any other module besides these.

# cat /proc/cpuinfo
processor    : 0
cpu        : e6500, altivec supported
clock        : 1466.666652MHz
revision    : 2.0 (pvr 8040 0120)
[ 7 identical cores more removed from this to avoid clutter ]
timebase    : 37500000
platform    : VPX3-133
model        : cw,vpx3-133

Attached buildroot's config:

BR2_powerpc64=y
BR2_powerpc_e6500=y
BR2_DL_DIR="$(BR2_EXTERNAL)/dl"
BR2_PACKAGE_OVERRIDE_FILE="$(BR2_EXTERNAL)/local.mk"
BR2_GLOBAL_PATCH_DIR="$(BR2_EXTERNAL)/patch"
BR2_KERNEL_HEADERS_3_10=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_GCC_ENABLE_LTO=y
BR2_GCC_ENABLE_OPENMP=y
BR2_ENABLE_LOCALE_PURGE=y
BR2_ENABLE_LOCALE_WHITELIST="C"
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_TARGET_GENERIC_GETTY_PORT="tty1"
BR2_ROOTFS_USERS_TABLES="$(BR2_EXTERNAL)/users.table"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="ssh://.../linux.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="tag"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL)/$(PROJECT_NAME)tag_defconfig"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_USE_CUSTOM_DTS=y
BR2_LINUX_KERNEL_CUSTOM_DTS_PATH="$(BR2_EXTERNAL)/$(PROJECT_NAME)/tag.dts"
BR2_PACKAGE_PYTHON=y
[ And the rest is just a selection of packages and non compiler nor kernel
related things ]


This only happens when using buildroot's toolchain.
One difference between buildroot's toolchain and the others,
is that buildroot's is the only one that supports a 64 bit target.

I don't know who can I debug that to provide more information,
but I'm willing to test whatever is needed.

Thank you, best regards

-- 
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151103/b7c57175/attachment.html>

[Buildroot] Illegal instruction by python's xmlrpclib on powerpc64, gcc-4.9

[Thomas Petazzoni]

Dear Alvaro Gamez,

Adding in Cc: some PowerPC folks: Gustavo Zacarias who added the 6500
config option, and Cody who added the initial PowerPC64 support.
Gustavo, Cody, can you look below ?

Alvaro, read only below for some suggestions.

Thanks!

Thomas

On Tue, 3 Nov 2015 10:40:09 +0100, Alvaro Gamez wrote:

> I'm trying to use xmlrpclib module from python on this architecture,
> but whenever I import that module I'm answered back with an 'Illegal
> instruction':
> 
> Python 2.7.10 (default, Oct 29 2015, 11:03:21)
> [GCC 4.9.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import xmlrpclib
> Illegal instruction
> 
> And this appears on dmesg:
> python[1439]: unhandled signal 4 at 00003fffb19ec6dc nip 00003fffb19ec6dc
> lr 00003fffb19ec6b0 code 30001
> 
> This doesn't happen when importing other modules, such as sys or os, but I
> haven't tested any other module besides these.
> 
> # cat /proc/cpuinfo
> processor    : 0
> cpu        : e6500, altivec supported
> clock        : 1466.666652MHz
> revision    : 2.0 (pvr 8040 0120)
> [ 7 identical cores more removed from this to avoid clutter ]
> timebase    : 37500000
> platform    : VPX3-133
> model        : cw,vpx3-133
> 
> Attached buildroot's config:
> 
> BR2_powerpc64=y
> BR2_powerpc_e6500=y
> BR2_DL_DIR="$(BR2_EXTERNAL)/dl"
> BR2_PACKAGE_OVERRIDE_FILE="$(BR2_EXTERNAL)/local.mk"
> BR2_GLOBAL_PATCH_DIR="$(BR2_EXTERNAL)/patch"
> BR2_KERNEL_HEADERS_3_10=y
> BR2_TOOLCHAIN_BUILDROOT_CXX=y
> BR2_GCC_ENABLE_LTO=y
> BR2_GCC_ENABLE_OPENMP=y
> BR2_ENABLE_LOCALE_PURGE=y
> BR2_ENABLE_LOCALE_WHITELIST="C"
> BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
> BR2_TARGET_GENERIC_GETTY_PORT="tty1"
> BR2_ROOTFS_USERS_TABLES="$(BR2_EXTERNAL)/users.table"
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_GIT=y
> BR2_LINUX_KERNEL_CUSTOM_REPO_URL="ssh://.../linux.git"
> BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="tag"
> BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL)/$(PROJECT_NAME)tag_defconfig"
> BR2_LINUX_KERNEL_DTS_SUPPORT=y
> BR2_LINUX_KERNEL_USE_CUSTOM_DTS=y
> BR2_LINUX_KERNEL_CUSTOM_DTS_PATH="$(BR2_EXTERNAL)/$(PROJECT_NAME)/tag.dts"
> BR2_PACKAGE_PYTHON=y
> [ And the rest is just a selection of packages and non compiler nor kernel
> related things ]
> 
> 
> This only happens when using buildroot's toolchain.
> One difference between buildroot's toolchain and the others,
> is that buildroot's is the only one that supports a 64 bit target.
> 
> I don't know who can I debug that to provide more information,
> but I'm willing to test whatever is needed.

Can you rebuild with BR2_ENABLE_DEBUG=y, then run "ulimit -c unlimited"
on your target, run the crashing Python stuff, grab back the "core"
file on your host machine, and 1 /look at the backtrace and 2/ at the
specific instruction that caused the crash ?

This would probably help quite a bit I believe.

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Illegal instruction by python's xmlrpclib on powerpc64, gcc-4.9

[Gustavo Zacarias]

On 03/11/15 11:17, Thomas Petazzoni wrote:

> Dear Alvaro Gamez,
>
> Adding in Cc: some PowerPC folks: Gustavo Zacarias who added the 6500
> config option, and Cody who added the initial PowerPC64 support.
> Gustavo, Cody, can you look below ?
>
> Alvaro, read only below for some suggestions.
>
> Thanks!
>
> Thomas
>
> Can you rebuild with BR2_ENABLE_DEBUG=y, then run "ulimit -c unlimited"
> on your target, run the crashing Python stuff, grab back the "core"
> file on your host machine, and 1 /look at the backtrace and 2/ at the
> specific instruction that caused the crash ?
>
> This would probably help quite a bit I believe.
>
> Thanks a lot!
>
> Thomas

Hi All.
I've added e5500/e6500 support with basic testing from Dwayne Fontenot, 
i never had any e5500/6500 hardware in my hands to test though, so it's 
kind of YMMV/best spare effort.
Testing with qemu_ppc64_pseries_defconfig which is the closest i can get 
seems to have no issues importing xmlrpclib, so a wild guess is that the 
toolchain has some bug with e6500 code generation, likely gcc.
Having a backtrace might help pinpoint a bit better, trying varying 
toolchain component versions would be a random test if not.
Regards.

[Buildroot] Illegal instruction by python's xmlrpclib on powerpc64, gcc-4.9

[Thomas Petazzoni]

Gustavo, Dwayne,

On Tue, 3 Nov 2015 16:20:36 -0300, Gustavo Zacarias wrote:

> I've added e5500/e6500 support with basic testing from Dwayne Fontenot, 
> i never had any e5500/6500 hardware in my hands to test though, so it's 
> kind of YMMV/best spare effort.

All right, so I'm adding Dwayne in Cc: to this e-mail so hopefully he
can help us by doing testing on real hardware.

Dwayne, can you have a look at the report at
http://lists.busybox.net/pipermail/buildroot/2015-November/143655.html
and see if you can reproduce or not on a PowerPC e6500 platform ?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Illegal instruction by python's xmlrpclib on powerpc64, gcc-4.9

[Alvaro Gamez]

Hi all

2015-11-03 15:17 GMT+01:00 Thomas Petazzoni <
thomas.petazzoni@free-electrons.com>:

> Can you rebuild with BR2_ENABLE_DEBUG=y, then run "ulimit -c unlimited"
> on your target, run the crashing Python stuff, grab back the "core"
> file on your host machine, and 1 /look at the backtrace and 2/ at the
> specific instruction that caused the crash ?
>

I've executed gdb python core inside the platform itself, so down below I'm
including the excerpts from the files mentioned in the backtrace:

#0  math_1 (can_overflow=0, func=<optimized out>, arg=<optimized out>)
    at /tmp/test/output/build/python-2.7.10/Modules/mathmodule.c:691
#1  math_sqrt (self=<optimized out>, args=<optimized out>)
    at /tmp/test/output/build/python-2.7.10/Modules/mathmodule.c:859
#2  0x00003fffabb4df3c in .PyEval_EvalFrameEx () from
/usr/lib64/libpython2.7.so.1.0
#3  0x00003fffabb4fe30 in .PyEval_EvalCodeEx () from
/usr/lib64/libpython2.7.so.1.0
#4  0x00003fffabb4ff4c in .PyEval_EvalCode () from
/usr/lib64/libpython2.7.so.1.0
... etc


As per #0:

build/python-2.7.10/Modules/mathmodule.c:691
static PyObject *
math_1(PyObject *arg, double (*func) (double), int can_overflow)
{
    double x, r;
    x = PyFloat_AsDouble(arg);
    if (x == -1.0 && PyErr_Occurred())
        return NULL;
    errno = 0;
    PyFPE_START_PROTECT("in math_1", return 0);
    r = (*func)(x);
    PyFPE_END_PROTECT(r);

The call to (*func) is the one raising the Illegal instruction:

And as per #1, the calling of this is:
/tmp/test/output/build/python-2.7.10/Modules/mathmodule.c:859
FUNC1(sqrt, sqrt, 0,
      "sqrt(x)\n\nReturn the square root of x.")

Somehow sqrt(x) is failing? Here is this function dissasembled by gdb:
Dump of assembler code for function math_sqrt:
   0x00003fff8f80c690 <+0>:    mflr    r0
   0x00003fff8f80c694 <+4>:    stfd    f30,-16(r1)
   0x00003fff8f80c698 <+8>:    stfd    f31,-8(r1)
   0x00003fff8f80c69c <+12>:    mr      r3,r4
   0x00003fff8f80c6a0 <+16>:    std     r31,-24(r1)
   0x00003fff8f80c6a4 <+20>:    std     r0,16(r1)
   0x00003fff8f80c6a8 <+24>:    stdu    r1,-144(r1)
   0x00003fff8f80c6ac <+28>:    bl      0x3fff8f806dac
<00000017.plt_call.PyFloat_AsDouble>
   0x00003fff8f80c6b0 <+32>:    ld      r2,40(r1)
   0x00003fff8f80c6b4 <+36>:    addis   r9,r2,-2
   0x00003fff8f80c6b8 <+40>:    lfs     f0,28480(r9)
   0x00003fff8f80c6bc <+44>:    fmr     f30,f1
   0x00003fff8f80c6c0 <+48>:    fcmpu   cr7,f1,f0
   0x00003fff8f80c6c4 <+52>:    bne     cr7,0x3fff8f80c6dc <math_sqrt+76>
   0x00003fff8f80c6c8 <+56>:    bl      0x3fff8f8070bc
<00000017.plt_call.PyErr_Occurred>
   0x00003fff8f80c6cc <+60>:    ld      r2,40(r1)
   0x00003fff8f80c6d0 <+64>:    li      r9,0
   0x00003fff8f80c6d4 <+68>:    cmpdi   cr7,r3,0
   0x00003fff8f80c6d8 <+72>:    bne     cr7,0x3fff8f80c73c <math_sqrt+172>
=> 0x00003fff8f80c6dc <+76>:    fsqrt   f31,f30


So, I've created the following test code:
#include <stdio.h>
#include <math.h>

int main(int argc, char *argv[])
{
    double d=4, sd;
    sd = sqrt(d);
    printf("%f\n", sd);
    return 0;
}

When compiled with NO optimizations, it receives SIGILL on:
Dump of assembler code for function .sqrtl:
   0x00003fffa154c690 <+0>:    addis   r9,r2,-6
   0x00003fffa154c694 <+4>:    fmr     f2,f1
   0x00003fffa154c698 <+8>:    lfd     f0,1240(r9)
   0x00003fffa154c69c <+12>:    fcmpu   cr7,f1,f0
   0x00003fffa154c6a0 <+16>:    blt     cr7,0x3fffa154c6b0 <.sqrtl+32>
=> 0x00003fffa154c6a4 <+20>:    fsqrt   f1,f2

When compiled with -O1, it doesn't receive SIGILL and correctly prints 2 as
sqrt(4).
The difference seems to be that without optimization, sqrt results in:
        bl sqrt
While when optimized, that call disappears.

After all this, it definitely seems to be that fsqrt instruction is the one
at fault here.
By doing a simple google search for "e6500 fsqrt" I've come across several
posts that seem to indicate that e6500's FPU does not in fact support fsqrt
instruction. For example, this:
http://lists.openembedded.org/pipermail/openembedded-core/2012-September/069345.html

I'm gonna be trying this again once the whole compilation finishes with
glibc-2.22, just in case it's been solved there. If not, I don't know if a
patch in the fashion of that in the mailing list above should be provided
for buildroot's glibc package or if it should be sent to glibc mailing
list, or possibly both.

Please, let me know if there's anything else I can test or how to provide
more information on this.

Best regards,

-- 
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151104/4ffd45f6/attachment.html>

[Buildroot] Illegal instruction by python's xmlrpclib on powerpc64, gcc-4.9

[Thomas Petazzoni]

Dear Alvaro Gamez,

On Wed, 4 Nov 2015 11:18:32 +0100, Alvaro Gamez wrote:

> Somehow sqrt(x) is failing? Here is this function dissasembled by gdb:
> Dump of assembler code for function math_sqrt:
>    0x00003fff8f80c690 <+0>:    mflr    r0
>    0x00003fff8f80c694 <+4>:    stfd    f30,-16(r1)
>    0x00003fff8f80c698 <+8>:    stfd    f31,-8(r1)
>    0x00003fff8f80c69c <+12>:    mr      r3,r4
>    0x00003fff8f80c6a0 <+16>:    std     r31,-24(r1)
>    0x00003fff8f80c6a4 <+20>:    std     r0,16(r1)
>    0x00003fff8f80c6a8 <+24>:    stdu    r1,-144(r1)
>    0x00003fff8f80c6ac <+28>:    bl      0x3fff8f806dac
> <00000017.plt_call.PyFloat_AsDouble>
>    0x00003fff8f80c6b0 <+32>:    ld      r2,40(r1)
>    0x00003fff8f80c6b4 <+36>:    addis   r9,r2,-2
>    0x00003fff8f80c6b8 <+40>:    lfs     f0,28480(r9)
>    0x00003fff8f80c6bc <+44>:    fmr     f30,f1
>    0x00003fff8f80c6c0 <+48>:    fcmpu   cr7,f1,f0
>    0x00003fff8f80c6c4 <+52>:    bne     cr7,0x3fff8f80c6dc <math_sqrt+76>
>    0x00003fff8f80c6c8 <+56>:    bl      0x3fff8f8070bc
> <00000017.plt_call.PyErr_Occurred>
>    0x00003fff8f80c6cc <+60>:    ld      r2,40(r1)
>    0x00003fff8f80c6d0 <+64>:    li      r9,0
>    0x00003fff8f80c6d4 <+68>:    cmpdi   cr7,r3,0
>    0x00003fff8f80c6d8 <+72>:    bne     cr7,0x3fff8f80c73c <math_sqrt+172>
> => 0x00003fff8f80c6dc <+76>:    fsqrt   f31,f30
> 
> 
> So, I've created the following test code:
> #include <stdio.h>
> #include <math.h>
> 
> int main(int argc, char *argv[])
> {
>     double d=4, sd;
>     sd = sqrt(d);
>     printf("%f\n", sd);
>     return 0;
> }
> 
> When compiled with NO optimizations, it receives SIGILL on:
> Dump of assembler code for function .sqrtl:
>    0x00003fffa154c690 <+0>:    addis   r9,r2,-6
>    0x00003fffa154c694 <+4>:    fmr     f2,f1
>    0x00003fffa154c698 <+8>:    lfd     f0,1240(r9)
>    0x00003fffa154c69c <+12>:    fcmpu   cr7,f1,f0
>    0x00003fffa154c6a0 <+16>:    blt     cr7,0x3fffa154c6b0 <.sqrtl+32>
> => 0x00003fffa154c6a4 <+20>:    fsqrt   f1,f2

Ok, so fsqrt is not available on this CPU core.

> When compiled with -O1, it doesn't receive SIGILL and correctly prints 2 as
> sqrt(4).
> The difference seems to be that without optimization, sqrt results in:
>         bl sqrt
> While when optimized, that call disappears.

Ah, yes. This is because gcc is smart and realizes that:

	double d = 4;
	sd = sqrt(d);

will always result to sd = 2, so at -O1, it optimizes that.

If you change your code to:

double foo(double a)
{
	return sqrt(a);
}

int main(void)
{
	printf("%f\n", foo(4));
}

then it should not be optimized, even at -O1. Or maybe it will be
optimized if foo() is in the same file as main() if gcc automatically
inlines the function. But if you put foo() in a separate C file, built
into its own object file, it for sure will not optimize (unless you
enable LTO).

> After all this, it definitely seems to be that fsqrt instruction is the one
> at fault here.
> By doing a simple google search for "e6500 fsqrt" I've come across several
> posts that seem to indicate that e6500's FPU does not in fact support fsqrt
> instruction. For example, this:
> http://lists.openembedded.org/pipermail/openembedded-core/2012-September/069345.html
> 
> I'm gonna be trying this again once the whole compilation finishes with
> glibc-2.22, just in case it's been solved there. If not, I don't know if a
> patch in the fashion of that in the mailing list above should be provided
> for buildroot's glibc package or if it should be sent to glibc mailing
> list, or possibly both.

I believe this problem might be fixed by glibc commit
08cee2a464f614a6d4275b5af6c52481f1aa16e6, which has been merged since
glibc 2.21. Which glibc version have you been using so far ?

See
https://sourceware.org/git/?p=glibc.git;a=commit;h=08cee2a464f614a6d4275b5af6c52481f1aa16e6
and https://sourceware.org/bugzilla/show_bug.cgi?id=16576.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Illegal instruction by python's xmlrpclib on powerpc64, gcc-4.9

[Alvaro Gamez]

Hi, Thomas

2015-11-04 11:49 GMT+01:00 Thomas Petazzoni <
thomas.petazzoni@free-electrons.com>:

> Dear Alvaro Gamez,
>
> Ok, so fsqrt is not available on this CPU core.
>
> I believe this problem might be fixed by glibc commit
> 08cee2a464f614a6d4275b5af6c52481f1aa16e6, which has been merged since
> glibc 2.21. Which glibc version have you been using so far ?
>
> See
>
> https://sourceware.org/git/?p=glibc.git;a=commit;h=08cee2a464f614a6d4275b5af6c52481f1aa16e6
> and https://sourceware.org/bugzilla/show_bug.cgi?id=16576.
>

Until now, I've been testing this with buildroots' glibc-2.21. I've just
done the same tests by selecting BR2_GLIBC_VERSION_2_22=y (I've confirmed
that libc.so.6 -> /lib64/libc-2.22.so), but it still compiles that with
fsqrt.

I've reviewed those patches and they are in fact applied on what buildroot
is downloading. However, that patch seems to depend on _ARCH_PPCSQ not
being defined.

I've found on host-gcc-final-4.9.3/gcc/config/rs6000:
  if ((flags & OPTION_MASK_PPC_GPOPT) != 0)
    rs6000_define_or_undefine_macro (define_p, "_ARCH_PPCSQ");

So it seems that this patch would make GPOPT be defined for e6500 CPU,
which in turn will avoid _ARCH_PPCSQ from being defined. I guess once I
test and very this, this should be a patch sent to the gcc people?

Thanks a lot for your guidance!


diff -urN host-gcc-final-4.9.3/gcc/config/rs6000/rs6000-cpus.def
host-gcc-final-4.9.3.mio/gcc/config/rs6000/rs6000-cpus.def
--- host-gcc-final-4.9.3/gcc/config/rs6000/rs6000-cpus.def    2015-11-04
12:30:01.539224474 +0100
+++ host-gcc-final-4.9.3.mio/gcc/config/rs6000/rs6000-cpus.def
2015-11-04 12:28:20.806611098 +0100
@@ -157,7 +157,7 @@
 RS6000_CPU ("e5500", PROCESSOR_PPCE5500,
         MASK_POWERPC64 | MASK_PPC_GFXOPT | MASK_ISEL)
 RS6000_CPU ("e6500", PROCESSOR_PPCE6500, POWERPC_7400_MASK | MASK_POWERPC64
-        | MASK_MFCRF | MASK_ISEL)
+        | MASK_MFCRF | MASK_ISEL | MASK_PPC_GPOPT)
 RS6000_CPU ("860", PROCESSOR_MPCCORE, MASK_SOFT_FLOAT)
 RS6000_CPU ("970", PROCESSOR_POWER4,
         POWERPC_7400_MASK | MASK_PPC_GPOPT | MASK_MFCRF | MASK_POWERPC64)



-- 
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151104/993469ad/attachment.html>

[Buildroot] Illegal instruction by python's xmlrpclib on powerpc64, gcc-4.9

[Alvaro Gamez]

Hi again!

2015-11-04 12:31 GMT+01:00 Alvaro Gamez <alvaro.gamez@hazent.com>:

>
> I've found on host-gcc-final-4.9.3/gcc/config/rs6000:
>   if ((flags & OPTION_MASK_PPC_GPOPT) != 0)
>     rs6000_define_or_undefine_macro (define_p, "_ARCH_PPCSQ");
>
> So it seems that this patch would make GPOPT be defined for e6500 CPU,
> which in turn will avoid _ARCH_PPCSQ from being defined. I guess once I
> test and very this, this should be a patch sent to the gcc people?
>
> diff -urN host-gcc-final-4.9.3/gcc/config/rs6000/rs6000-cpus.def
> host-gcc-final-4.9.3.mio/gcc/config/rs6000/rs6000-cpus.def
> --- host-gcc-final-4.9.3/gcc/config/rs6000/rs6000-cpus.def    2015-11-04
> 12:30:01.539224474 +0100
> +++ host-gcc-final-4.9.3.mio/gcc/config/rs6000/rs6000-cpus.def
> 2015-11-04 12:28:20.806611098 +0100
> @@ -157,7 +157,7 @@
>  RS6000_CPU ("e5500", PROCESSOR_PPCE5500,
>          MASK_POWERPC64 | MASK_PPC_GFXOPT | MASK_ISEL)
>  RS6000_CPU ("e6500", PROCESSOR_PPCE6500, POWERPC_7400_MASK |
> MASK_POWERPC64
> -        | MASK_MFCRF | MASK_ISEL)
> +        | MASK_MFCRF | MASK_ISEL | MASK_PPC_GPOPT)
>  RS6000_CPU ("860", PROCESSOR_MPCCORE, MASK_SOFT_FLOAT)
>  RS6000_CPU ("970", PROCESSOR_POWER4,
>          POWERPC_7400_MASK | MASK_PPC_GPOPT | MASK_MFCRF | MASK_POWERPC64)
>
>
I've tried to test this, but before I realized that buildroot didn't
include support for mcpu=e6500, so I applied the following patch:
diff --git a/arch/Config.in.powerpc b/arch/Config.in.powerpc
index 95bcaee..cafafea 100644
--- a/arch/Config.in.powerpc
+++ b/arch/Config.in.powerpc
@@ -200,6 +200,7 @@ config BR2_GCC_TARGET_CPU
        default "e300c2"        if BR2_powerpc_e300c2
        default "e300c3"        if BR2_powerpc_e300c3
        default "e500mc"        if BR2_powerpc_e500mc
+       default "e6500"         if BR2_powerpc_e6500
        default "power4"        if BR2_powerpc_power4
        default "power5"        if BR2_powerpc_power5
        default "power6"        if BR2_powerpc_power6

Now, however, the problem is pretty different, as when compiling glibc, I
stumbled upon this:

../sysdeps/powerpc/powerpc64/start.S: Assembler messages:
../sysdeps/powerpc/powerpc64/start.S:77: Error: syntax error; found `@',
expected `('
../sysdeps/powerpc/powerpc64/start.S:77: Error: junk at end of line:
`@toc(2)'
[...]
../sysdeps/powerpc/powerpc64/crtn.S: Assembler messages:
../sysdeps/powerpc/powerpc64/crtn.S:42: Error: unsupported relocation
against FRAME_MIN_SIZE_PARM
../sysdeps/powerpc/powerpc64/crtn.S:48: Error: unsupported relocation
against FRAME_MIN_SIZE_PARM
[...]
../sysdeps/powerpc/powerpc64/crti.S: Assembler messages:
../sysdeps/powerpc/powerpc64/crti.S:64: Error: unrecognized opcode:
`entry_2(_init)'
../sysdeps/powerpc/powerpc64/crti.S:66: Error: unrecognized opcode:
`body_label'
../sysdeps/powerpc/powerpc64/crti.S:67: Error: unrecognized opcode:
`localentry(_init)'
../sysdeps/powerpc/powerpc64/crti.S:72: Error: syntax error; found `@',
expected `,'
../sysdeps/powerpc/powerpc64/crti.S:72: Error: junk at end of line: `@toc at ha
'
../sysdeps/powerpc/powerpc64/crti.S:73: Error: syntax error; found `@',
expected `('
../sysdeps/powerpc/powerpc64/crti.S:73: Error: junk at end of line: `@toc at l
(9)'
../sysdeps/powerpc/powerpc64/crti.S:82: Error: unrecognized opcode:
`entry_2(_fini)'
../sysdeps/powerpc/powerpc64/crti.S:84: Error: unrecognized opcode:
`body_label'
../sysdeps/powerpc/powerpc64/crti.S:85: Error: unrecognized opcode:
`localentry(_fini)'
[...]
../sysdeps/powerpc/powerpc64/dl-machine.h: In function
'elf_machine_runtime_setup':
../sysdeps/powerpc/powerpc64/dl-machine.h:342:26: error: initialization
from incompatible pointer type [-Werror]
       Elf64_Dyn **info = map->l_info;
../sysdeps/powerpc/powerpc64/dl-machine.h:361:11: error: cast from pointer
to integer of different size [-Werror=pointer-to-int-cast]
    dlrr = (Elf64_Addr) (profile ? _dl_profile_resolve
[Several other identical errors referring to different casts]
[...]
/tmp/test/build/glibc-2.21/build/gnu/lib-names.h:10:31: fatal error:
gnu/lib-names-32.h: No such file or directory
compilation terminated.
/tmp/test/build/glibc-2.21/build/sysd-rules:857: recipe for target
'/tmp/test/build/glibc-2.21/build/csu/unwind-resume.os' failed


And now I just simply don't know how to continue. Any ideas? This toolchain
with previous patch to buildroot results in
Using built-in specs.
COLLECT_GCC=/test/output/host/usr/bin/powerpc64-buildroot-linux-gnu-gcc.br_real
COLLECT_LTO_WRAPPER=/test/output/host/usr/libexec/gcc/powerpc64-buildroot-linux-gnu/4.9.3/lto-wrapper
Target: powerpc64-buildroot-linux-gnu
Configured with: ./configure  --prefix=/test/output/host/usr
--sysconfdir=/test/output/host/etc  --localstatedir=/test/output/host/var
--enable-shared  --disable-static  --disable-gtk-doc
--disable-gtk-doc-html  --disable-doc  --disable-docs
--disable-documentation  --disable-debug  --with-xmlto=no  --with-fop=no
--disable-dependency-tracking  --target=powerpc64-buildroot-linux-gnu
--with-sysroot=/test/output/host/usr/powerpc64-buildroot-linux-gnu/sysroot
--disable-__cxa_atexit  --with-gnu-ld  --disable-libssp
--disable-multilib  --with-gmp=/test/output/host/usr
--with-mpfr=/test/output/host/usr  --with-pkgversion='Buildroot
2015.11-git-00919-g73eb930-dirty'  --with-bugurl=http://bugs.buildroot.net/
--disable-libquadmath  --enable-tls  --disable-libmudflap
--enable-threads  --with-mpc=/test/output/host/usr  --without-isl
--without-cloog  --disable-decimal-float  --with-cpu=e6500
--enable-languages=c  --disable-shared  --without-headers
--disable-threads  --with-newlib  --disable-largefile  --disable-nls
Thread model: single
gcc version 4.9.3 (Buildroot 2015.11-git-00919-g73eb930-dirty)


Thanks, best regards!

-- 
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151104/a4c125fe/attachment.html>

[Buildroot] Illegal instruction by python's xmlrpclib on powerpc64, gcc-4.9

[Arnout Vandecappelle]

On 04-11-15 16:24, Alvaro Gamez wrote:
[snip]
> I've tried to test this, but before I realized that buildroot didn't include
> support for mcpu=e6500, so I applied the following patch:
> diff --git a/arch/Config.in.powerpc b/arch/Config.in.powerpc
> index 95bcaee..cafafea 100644
> --- a/arch/Config.in.powerpc
> +++ b/arch/Config.in.powerpc
> @@ -200,6 +200,7 @@ config BR2_GCC_TARGET_CPU
>         default "e300c2"        if BR2_powerpc_e300c2
>         default "e300c3"        if BR2_powerpc_e300c3
>         default "e500mc"        if BR2_powerpc_e500mc
> +       default "e6500"         if BR2_powerpc_e6500
>         default "power4"        if BR2_powerpc_power4
>         default "power5"        if BR2_powerpc_power5
>         default "power6"        if BR2_powerpc_power6

 Right, Gustavo forgot to add that when he added e5500 and e6500. Patch follows.

> 
> Now, however, the problem is pretty different, as when compiling glibc, I
> stumbled upon this:
> 
> ../sysdeps/powerpc/powerpc64/start.S: Assembler messages:
> ../sysdeps/powerpc/powerpc64/start.S:77: Error: syntax error; found `@',
> expected `('
> ../sysdeps/powerpc/powerpc64/start.S:77: Error: junk at end of line: `@toc(2)'
> [...]
> ../sysdeps/powerpc/powerpc64/crtn.S: Assembler messages:
> ../sysdeps/powerpc/powerpc64/crtn.S:42: Error: unsupported relocation against
> FRAME_MIN_SIZE_PARM
> ../sysdeps/powerpc/powerpc64/crtn.S:48: Error: unsupported relocation against
> FRAME_MIN_SIZE_PARM
> [...]
> ../sysdeps/powerpc/powerpc64/crti.S: Assembler messages:
> ../sysdeps/powerpc/powerpc64/crti.S:64: Error: unrecognized opcode: `entry_2(_init)'
> ../sysdeps/powerpc/powerpc64/crti.S:66: Error: unrecognized opcode: `body_label'
> ../sysdeps/powerpc/powerpc64/crti.S:67: Error: unrecognized opcode:
> `localentry(_init)'
> ../sysdeps/powerpc/powerpc64/crti.S:72: Error: syntax error; found `@', expected `,'
> ../sysdeps/powerpc/powerpc64/crti.S:72: Error: junk at end of line: `@toc at ha'
> ../sysdeps/powerpc/powerpc64/crti.S:73: Error: syntax error; found `@', expected `('
> ../sysdeps/powerpc/powerpc64/crti.S:73: Error: junk at end of line: `@toc at l(9)'
> ../sysdeps/powerpc/powerpc64/crti.S:82: Error: unrecognized opcode: `entry_2(_fini)'
> ../sysdeps/powerpc/powerpc64/crti.S:84: Error: unrecognized opcode: `body_label'
> ../sysdeps/powerpc/powerpc64/crti.S:85: Error: unrecognized opcode:
> `localentry(_fini)'
> [...]
> ../sysdeps/powerpc/powerpc64/dl-machine.h: In function 'elf_machine_runtime_setup':
> ../sysdeps/powerpc/powerpc64/dl-machine.h:342:26: error: initialization from
> incompatible pointer type [-Werror]
>        Elf64_Dyn **info = map->l_info;
> ../sysdeps/powerpc/powerpc64/dl-machine.h:361:11: error: cast from pointer to
> integer of different size [-Werror=pointer-to-int-cast]
>     dlrr = (Elf64_Addr) (profile ? _dl_profile_resolve
> [Several other identical errors referring to different casts]
> [...]
> /tmp/test/build/glibc-2.21/build/gnu/lib-names.h:10:31: fatal error:
> gnu/lib-names-32.h: No such file or directory
> compilation terminated.
> /tmp/test/build/glibc-2.21/build/sysd-rules:857: recipe for target
> '/tmp/test/build/glibc-2.21/build/csu/unwind-resume.os' failed
> 
> 
> And now I just simply don't know how to continue. Any ideas?

 The problem is that the compiler doesn't seem to build 64-bit binaries unless
-m64 is specified, but glibc is configured for 64-bit.

 Just adding -m64 to BR2_TARGET_OPTIMIZATION works around the issue.

 Now that we have the toolchain wrapper, we could just add -DBR_64 in
toolchain-wrapper.mk whenever BR2_ARCH_IS_64. However, I'm not sure how that
will play with n32, ilp32 and x32 ABIs. Adding Vicente, Bamvor and Guido who
added those ABIs.


 Regards,
 Arnout

> This toolchain with
> previous patch to buildroot results in
> Using built-in specs.
> COLLECT_GCC=/test/output/host/usr/bin/powerpc64-buildroot-linux-gnu-gcc.br_real
> COLLECT_LTO_WRAPPER=/test/output/host/usr/libexec/gcc/powerpc64-buildroot-linux-gnu/4.9.3/lto-wrapper
> Target: powerpc64-buildroot-linux-gnu
> Configured with: ./configure  --prefix=/test/output/host/usr 
> --sysconfdir=/test/output/host/etc  --localstatedir=/test/output/host/var 
> --enable-shared  --disable-static  --disable-gtk-doc  --disable-gtk-doc-html 
> --disable-doc  --disable-docs  --disable-documentation  --disable-debug 
> --with-xmlto=no  --with-fop=no  --disable-dependency-tracking 
> --target=powerpc64-buildroot-linux-gnu 
> --with-sysroot=/test/output/host/usr/powerpc64-buildroot-linux-gnu/sysroot 
> --disable-__cxa_atexit  --with-gnu-ld  --disable-libssp  --disable-multilib 
> --with-gmp=/test/output/host/usr  --with-mpfr=/test/output/host/usr 
> --with-pkgversion='Buildroot 2015.11-git-00919-g73eb930-dirty' 
> --with-bugurl=http://bugs.buildroot.net/  --disable-libquadmath  --enable-tls 
> --disable-libmudflap  --enable-threads  --with-mpc=/test/output/host/usr 
> --without-isl  --without-cloog  --disable-decimal-float  --with-cpu=e6500 
> --enable-languages=c  --disable-shared  --without-headers  --disable-threads 
> --with-newlib  --disable-largefile  --disable-nls
> Thread model: single
> gcc version 4.9.3 (Buildroot 2015.11-git-00919-g73eb930-dirty)
> 
> 
> Thanks, best regards!
> 
> -- 
> ?lvaro G?mez Machado
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Illegal instruction by python's xmlrpclib on powerpc64, gcc-4.9

[Alvaro Gamez]

Hi, Arnout

2015-11-04 23:48 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:

>  The problem is that the compiler doesn't seem to build 64-bit binaries
> unless
> -m64 is specified, but glibc is configured for 64-bit.
>
>  Just adding -m64 to BR2_TARGET_OPTIMIZATION works around the issue.
>
>
Well... that's seems to be not enough, as after adding this, compilation
still fails:

/tmp/test/output/host/usr/bin/powerpc64-buildroot-linux-gnu-gcc   -nostdlib
-nostartfiles -r -o
/tmp/test/output/build/glibc-2.21/build/elf/librtld.map.o
'-Wl,-('/tmp/test/output/build/glibc-2.21/build/elf/dl-allobjs.os
/tmp/test/output/build/glibc-2.21/build/libc_pic.a -lgcc '-Wl,-)'
-Wl,-Map,/tmp/test/output/build/glibc-2.21/build/elf/librtld.mapT
/tmp/test/output/host/usr/lib/gcc/powerpc64-buildroot-linux-gnu/4.9.3/../../../../powerpc64-buildroot-linux-gnu/bin/ld:
skipping incompatible
/tmp/test/output/host/usr/lib/gcc/powerpc64-buildroot-linux-gnu/4.9.3/libgcc.a
when searching for -lgcc
/tmp/test/output/host/usr/lib/gcc/powerpc64-buildroot-linux-gnu/4.9.3/../../../../powerpc64-buildroot-linux-gnu/bin/ld:
cannot find -lgcc
collect2: error: ld returned 1 exit status

If I also set BR2_TARGET_LDFLAGS="-melf64ppc", then the following happens:

checking whether __attribute__((visibility())) is supported... yes
checking for broken __attribute__((visibility()))... no
checking for broken __attribute__((alias()))... no
checking whether to put _rtld_local into .sdata section... no
checking for .preinit_array/.init_array/.fini_array support... no
configure: error: Need linker with .init_array/.fini_array support.
package/pkg-generic.mk:178: recipe for target
'/tmp/test/output/build/glibc-2.21/.stamp_configured' failed
make[1]: *** [/tmp/test/output/build/glibc-2.21/.stamp_configured] Error 1
common.mk:41: recipe for target 'default' failed
make: *** [default] Error 2

Patching toolchain-wrapper.mk as you suggested:
diff --git a/toolchain/toolchain-wrapper.mk b/toolchain/toolchain-wrapper.mk
index af39071..de9124c 100644
--- a/toolchain/toolchain-wrapper.mk
+++ b/toolchain/toolchain-wrapper.mk
@@ -30,6 +30,10 @@ ifeq ($(BR2_CCACHE_USE_BASEDIR),y)
 TOOLCHAIN_WRAPPER_ARGS += -DBR_CCACHE_BASEDIR='"$(BASE_DIR)"'
 endif

+ifeq ($(BR2_ARCH_IS_64),y)
+TOOLCHAIN_WRAPPER_ARGS += -DBR_64
+endif
+
 # For simplicity, build directly into the install location
 define TOOLCHAIN_BUILD_WRAPPER
        $(Q)mkdir -p $(HOST_DIR)/usr/bin

The end result is the same as the first case, with ld complaining about
-lgcc

Best regards

-- 
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151105/b0001e88/attachment.html>

[Buildroot] Illegal instruction by python's xmlrpclib on powerpc64, gcc-4.9

[Arnout Vandecappelle]

On 05-11-15 11:27, Alvaro Gamez wrote:
> Hi, Arnout
>
> 2015-11-04 23:48 GMT+01:00 Arnout Vandecappelle <arnout@mind.be
> <mailto:arnout@mind.be>>:
>
>      The problem is that the compiler doesn't seem to build 64-bit binaries unless
>     -m64 is specified, but glibc is configured for 64-bit.
>
>      Just adding -m64 to BR2_TARGET_OPTIMIZATION works around the issue.
>
>
> Well... that's seems to be not enough, as after adding this, compilation still
> fails:
>
> /tmp/test/output/host/usr/bin/powerpc64-buildroot-linux-gnu-gcc   -nostdlib
> -nostartfiles -r -o /tmp/test/output/build/glibc-2.21/build/elf/librtld.map.o
> '-Wl,-('/tmp/test/output/build/glibc-2.21/build/elf/dl-allobjs.os
> /tmp/test/output/build/glibc-2.21/build/libc_pic.a -lgcc '-Wl,-)'
> -Wl,-Map,/tmp/test/output/build/glibc-2.21/build/elf/librtld.mapT
>
/tmp/test/output/host/usr/lib/gcc/powerpc64-buildroot-linux-gnu/4.9.3/../../../../powerpc64-buildroot-linux-gnu/bin/ld:
> skipping incompatible
> /tmp/test/output/host/usr/lib/gcc/powerpc64-buildroot-linux-gnu/4.9.3/libgcc.a
> when searching for -lgcc
>
/tmp/test/output/host/usr/lib/gcc/powerpc64-buildroot-linux-gnu/4.9.3/../../../../powerpc64-buildroot-linux-gnu/bin/ld:
> cannot find -lgcc
> collect2: error: ld returned 1 exit status

Oops, you're right, I wrote my mail before compilation was completely finished...

So we have to convince gcc to really build a ppc64 compiler. I can't readily
find a configure option to do that - except for the powerpc64-* tuple which we
already set.

 Any ppc64 expert out there that can give a hint? Gustavo?

>
> If I also set BR2_TARGET_LDFLAGS="-melf64ppc", then the following happens:
>
> checking whether __attribute__((visibility())) is supported... yes
> checking for broken __attribute__((visibility()))... no
> checking for broken __attribute__((alias()))... no
> checking whether to put _rtld_local into .sdata section... no
> checking for .preinit_array/.init_array/.fini_array support... no
> configure: error: Need linker with .init_array/.fini_array support.
> package/pkg-generic.mk:178 <http://pkg-generic.mk:178>: recipe for target
> '/tmp/test/output/build/glibc-2.21/.stamp_configured' failed
> make[1]: *** [/tmp/test/output/build/glibc-2.21/.stamp_configured] Error 1
> common.mk:41 <http://common.mk:41>: recipe for target 'default' failed
> make: *** [default] Error 2
>
> Patching toolchain-wrapper.mk <http://toolchain-wrapper.mk> as you suggested:
> diff --git a/toolchain/toolchain-wrapper.mk <http://toolchain-wrapper.mk>
> b/toolchain/toolchain-wrapper.mk <http://toolchain-wrapper.mk>
> index af39071..de9124c 100644
> --- a/toolchain/toolchain-wrapper.mk <http://toolchain-wrapper.mk>
> +++ b/toolchain/toolchain-wrapper.mk <http://toolchain-wrapper.mk>
> @@ -30,6 +30,10 @@ ifeq ($(BR2_CCACHE_USE_BASEDIR),y)
>  TOOLCHAIN_WRAPPER_ARGS += -DBR_CCACHE_BASEDIR='"$(BASE_DIR)"'
>  endif
>
> +ifeq ($(BR2_ARCH_IS_64),y)
> +TOOLCHAIN_WRAPPER_ARGS += -DBR_64
> +endif
> +
>  # For simplicity, build directly into the install location
>  define TOOLCHAIN_BUILD_WRAPPER
>         $(Q)mkdir -p $(HOST_DIR)/usr/bin
>
> The end result is the same as the first case, with ld complaining about -lgcc

Obviously, since it has exactly the same effect as setting it in
BR2_TARGET_OPTIMIZATION.


Regards,
Arnout

>
> Best regards
>
> --
> ?lvaro G?mez Machado


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF