Cross compiling for raspberry pi

[Milan Pandurov]

I am having a problem with cross compiling google v8 libraries for raspberry pi, and constantly getting "Illegal instruction" error when compiling official sample from site. These are the steps i followed:

1. Downloaded cross compile https://github.com/raspberrypi/tools/
2. Cloned v8 git https://chromium.googlesource.com/v8/v8.git
3. Exported CXX LINK point to arm-linux-gnueabihf-g++ from cross compile tools.
4. run make arm.release armv7=false hardfp=on snapshot=off armfpu=vfp armfloatabi=hard -j5
5. Copied generated executable shell and d8 from out/arm.release directory to pi (Raspbian kernel version 3.6.11) and it WORKS. These steps prove that cross compilation toolchain is functional.
   

Problem occurs when trying to run other cross-compiled software that is linked to v8 libraries. For example sample code from https://developers.google.com/v8/get_started#intro. Code is cross-compiled with this command (same as example, just changed compiler)

arm-linux-gnueabihf-g++ -I. hello_world.cc -o hello_world -Wl,--start-group out/x64.release/obj.target/{tools/gyp/libv8_{base,libbase,snapshot,libplatform},third_party/icu/libicu{uc,i18n,data}}.a -Wl,--end-group -lrt -pthread

When i copy that code to pi and run it i get SIGILL (Illegal instruction).

Note: cross compiled software that doesn't use v8 libraries works fine. Also x64 v8 libraries on host computer work fine.

On newer kernel versions shell and d8 were also throwing SIGILL but than i switched to older version 3.6.11 (problems with newer kernel https://groups.google.com/forum/#!topic/v8-users/IPT9EeYK9bg) and they started working, but compiled sample code is still showed same issues.

Did anyone have similar experience? Any suggestion on how to overcome this problem?

[Flying Jester]

It might be that the old ISA the rPi uses is just too old to run V8.

Generally, the devs only care about the devices that can also run Android.

[Milan Pandurov]

That's pretty sad. I noticed that there are not many threads concerning raspberry pi and v8. But there are also some people who managed to make it work, so i guess that in some point in time there was a working git commit + version of raspberry or some platform specific hack that worked.

Also if you suggest that raspberry pi isn't "supported" than looking for an alternative is a better solution than hacking this to work?

[Rodolph Perfetta]

I may be missing something but in your example you are using x64 libs in your cross compilation, how could this work?

Rodolph.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dean McNamee]

I've built a few versions of v8 on the raspberry pi with no major
trouble. There has always been small hiccups, but the last time the
bugs I were filed and fixed. For example:

https://github.com/joyent/node/issues/8549

It could just be a matter of building incorrectly. What is the
illegal instruction? That will be a good starting point, and then
work back through all of the defines to make sure you have all of the
features / defines set correctly.

[Milan Pandurov]

That x64 build was just an reference that it works on host pc. It has nothing to do with cross compiling. 

[Flying Jester]

I forget if such a thing exists, but perhaps there is a switch to compile for older ARM versions?

[Rodolph Perfetta]

The first thing I would check would be the compilation options when targeting the Pi: did you put -march=armv6, -mfpu=vfpv2 (-mfloat-abi=hard sounds like the default on your toolchain) or are they already your toolchain default? Most cross toolchains default to ARMv7, VFPv3.

If the compilation options are correct, then could you provide more details: what is the sigill and where is it. GDB should be able to tell you those things.

Cheers,

Rodolph.

[Flying Jester]

I actually think it would be vastly easier to just compile on the rPi itself with a native toolchain. I did this about a year ago, and it went fairly well.

[Milan Pandurov]

When running hello_world in gdb it breaks:

Local<Context> context = Context::New(isolate);

i haven't compiled debug version of library, but backtrace shows this.

Program received signal SIGILL, Illegal instruction.

0x23b1375c in ?? ()

(gdb) backtrace

#0  0x23b1375c in ?? ()

#1  0x23b6bf90 in ?? ()

#2  0x23b6bf90 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I didn't understand you completely on a process of finding illegal instruction. Could you clarify this a bit. 

Could you remember which build arguments were you using when building your project library.

Thanks

[Flying Jester]

I probably used ALL the arguments that disabled any features (no snapshot, armv6, regexp as interpreted, no ICU, no hardware FPU, etc). And I also recommend building the debug build, and then running the included tests.

That's what I would try.

[Ben Noordhuis]

On Fri, Jan 9, 2015 at 8:16 PM, Milan Pandurov <milanp...@gmail.com> wrote:
> When running hello_world in gdb it breaks:
>
> Local<Context> context = Context::New(isolate);
>
> i haven't compiled debug version of library, but backtrace shows this.
>
> Program received signal SIGILL, Illegal instruction.
> 0x23b1375c in ?? ()
> (gdb) backtrace
> #0 0x23b1375c in ?? ()
> #1 0x23b6bf90 in ?? ()
> #2 0x23b6bf90 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> I didn't understand you completely on a process of finding illegal
> instruction. Could you clarify this a bit.
> Could you remember which build arguments were you using when building your
> project library.
>
> Thanks

Try `disassemble` when you get the SIGILL, that should print the
offending instruction.

[Milan Pandurov]

unit test fails on 

[----------] 6 tests from ChangeLowering32Test

[ RUN      ] ChangeLowering32Test.ChangeInt32ToTagged

Illegal instruction

[Milan Pandurov]

Ok i managed to solve this problem. Solution is different make arguments. This is a solution that works for me:

make arm.release arm_version=6 armfpu=vfp armfloatabi=hard

Now all unit tests pass, sample code and my program all work nicely. 

I will check if it works on newer kernel version and post here.

Thanks for help people

[Flying Jester]

I would guess the `arm_version=6` is what makes the difference. Almost nothing is arm6 anymore, so it makes sense that V8 would default to outputting arm7 asm.