Cross-compiling for MPC5200B (e300 core) results in Illegal Instruction

[stw-technic]

To compile, I run the following..

this is the toolchain, accessible by the $PATH env variable

export CXX=powerpc-stw-linux-uclibc-g++
export LINK==powerpc-stw-linux-uclibc-g++
make ppc -j8 snapshot=off

The compilation without snapshot appears successful. http://pastebin.com/YTXYcJ4S

To test v8, I was planning on using the 'shell' application that is built. So I navigated to the output directory and ran ‘file’ on the shell application. The output confirms that the application was built for my target.
shell: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked (uses shared libs), with unknown capability 0x41000000 = 0x13676e75, with unknown capability 0x10000 = 0xb0401, not stripped

If I run the ‘release’ shell application on the target, I get an Illegal Instruction (SIGILL). If I run the ‘debug’ shell application, I get a Segmentation fault (SIGTRAP).

Here is some gdb output. http://pastebin.com/WqvSMjtF

Andrew Low stated that there may be missing instructions on my architecture. I believe that the MPC5200B is an e300 architecture, which may not have some of the assembly instructions.

The user manual for MPC5200 is here:
http://cache.freescale.com/files/32bit/doc/ref_manual/MPC5200BUM.pdf

The reference manual for the e300 core is here (this is used by MPC5200) :
http://cache.freescale.com/files/32bit/doc/ref_manual/e300coreRM.pdf

Looking at appendix A in the e300 core RM, you may find some of the instructions that are being used that arent implemented in the e300 core instruction set.

It appears that our instruction cache is 16 KB and our data cache is 16 KB.

After reading through issues #99 and #100, it seems that my issue could potentially be similar.

from issue 100, i cross checked some of the instructions with what is supported in the e300 instruction set, and just from the output you (Andrew) wrote I can see that fsqrt, fctid, and fctidz are not supported.

I'll do some more digging. Worst case scenario, I can send one of our microcontrollers that this is on. http://www.stw-technic.com/products/teleservice/esx-tc3/

[andrewlow]

Given the data above, it is clear that the current implementation is trying to use some of the unsupported instructions.

@bberrySTW it'd be great to have some hardware locally that I can bang away on - support on the e500v2 has been hampered by lack of good access to hardware. I can't make any promises in terms of how quickly we can address these issues, I work for IBM and their product plans drive my priority list. This is an open source project, and I welcome contributions from others.

Maybe we'll get lucky and he e300 and e500v2 are 'similar' enough that work on one will benefit the other (but a quick glance at the manual says they aren't really that close). You can in theory use the "build with the nativesim=true flag" hack - but that's not a production solution.

[stw-technic]

I saw in another post you (@andrewlow) stated to do
make ppc nativesim=true library=shared
and
./configure --shared-v8 --shared-v8-includes ~/v8ppc/include --shared-v8-libpath ~/v8ppc/out/ppc.release/lib.target
make

Instead of using dynamic libs when running node, could i use pre-built static v8 libs instead? It looks like to me that node is compiling v8 then using static v8 libs to build node, so i guess i would just need to reroute that.

Or instead of pointing the node compilation to static v8 libs, i could just do
make ppc -j6 snapshot=off nativesim=true
for v8 wherever it gets compiled for node (not sure where that is or how it gets made up in all the files, gyp and python are new to me!).

I think I 'could' use dynamic libs on my microcontroller flash, but if it's easy to do I'd much prefer to use static libs instead.

[andrewlow]

Those instructions were for building Node.js with a simulated version of v8.

The node source tree contains an embedded version of v8 in the deps directory. If you look at https://github.com/andrewlow/node you'll notice that we've added a deps/v8ppc that is used when building that code on a PowerPC platform. This was done to try to isolate the changes we needed to make to support PowerPC.

The V8 source can be built on PowerPC in simulation mode on Intel, and with the nativesim=true flag we can also force the simulation mode to be used when running on native PowerPC (with an associated slow down penalty due to simulation). By doing this we can get the code to run on platforms that don't quite work (like the e300 in this case). It's a horrible hack.

There is probably a way to link this statically - by hacking the node GYP files etc. I'll leave that as an exercise to the reader :) Given that building in nativesim mode is a complete hack, the extra cost/pain of running with shared libraries is sort of insignificant.

[andrewlow]

if you just want a static version of v8

 make ppc nativesim=true

will build one.

[andrewlow]

I failed to update this item. @bberrySTW sent me a development board to look at - I've finally got a few free moments to take a look. At this point I'm just past the initial setup and have replicated the problem (I'm seeing an illegal instruction).

[andrewlow]

The http://cache.freescale.com/files/32bit/doc/ref_manual/e300coreRM.pdf manual calls out a number of "Instruction not implemented in the e300 core" - the current V8 PPC implementation is hitting several of these.

The first I encountered was..

fcfid   d6, d6

but scanning the list of unimplemented instructions it's clear there are going to be others.

[jscottandersonthe1]

I know this thread is old, but has anyone come up with an alternative for that exact op-code (fcfid)?

I've dug in to this problem and see that that instruction is encountered frequently when starting up the d8 shell. It looks like I have to come up with working alternatives for {fctiwz, fcfid, fsqrt} for a start.

[tunniclm]

@jscottandersonthe1 the g4compat branch has some changes to address the missing instructions. However, it is now structurally out-of-date. Check this function https://github.com/andrewlow/v8ppc/blob/841840ef1dcd4f36a7dc5f4a0ffac74738cb972c/src/ppc/code-stubs-ppc.cc#L663 for an alternative to fcfid (for comparison, the same function using fcfid is https://github.com/andrewlow/v8ppc/blob/841840ef1dcd4f36a7dc5f4a0ffac74738cb972c/src/ppc/code-stubs-ppc.cc#L711).

I needed to replace fctidz, but not fctiwz for the platform I was targetting. So I'm not sure about that one.

For fsqrt I cheated and injected a callback into the C runtime. Although I noticed there seemed to be some rounding errors sometimes (recreatable in a standalone C program).

[jscottandersonthe1]

@tunniclm Thanks Mike. You pointed me right at a solution (I think). I checked out the g4compat branch and built it using my cross compiler tools. The d8 shell runs fine on my e300c4 core. All I had to do was change some -Werror flags to -Wno-error to get it to compile.

My objective is to host node on my board, so this gets me closer. Can you tell me the rough implications of this branch being structurally out of date?

Just to fill in the picture some, my system reports AT_PLATFORM: ppc603

I hope anyone else who comes along here trying to bring up v8 on a e300 core can get a lift from this information, though I doubt there are that many out there.

[tunniclm]

@jscottandersonthe1 The g4compat branch is based on what is now a fairly old version of V8. I had a look a few months back at what would be required to bring it to a more recent V8 version and found that the code had changes enough to make it a non-trivial task.