Compiler errors and crashes on RaspberryPi 2

[Kyle Summers]

Hi,

Following a few length build processes I've got extempore up and running on a Rasberry Pi 2.

I'm having difficult moving past my current sticking point.

Simple instructions are able to be compiled/executed without any issues, for example (+ 1 2) returns 3, (bind-val pi double 3.1415) results in SetValue:   pi >>> double in the extempore server stdout.

When attempting any of the examples from http://benswift.me/2012/09/26/interacting-with-the-extempore-compiler/, I get a number of type errors.

For example:

(bind-func circle_area

    (lambda (r)

        (* (pow r 2.0) pi)))

Results in:

Type Error couldn't resolve types: (r circle_area) you could try forcing the type of one or more of these symbols

With examples from core/extempore_lang.xtm I often see a 'compiled' trace, followed by crash citing SIGABRT.

For example:

(bind-func my-test-1

    (lambda (a)

        (/ a 5)))

Results in:

Compiled: my-test-1 >>> [i64,i64]* sone size: 8192 (default)

  <unfinished ...>

+++ killed by SIGABRT +++

Aborted

The third and second last lines are output from strace, 'Aborted' is the only message on stdout. There is no aborted message at all if extempore is run as root.

Any thoughts on what the issue(s) might be, or even just pointers in a particular direction for troubleshooting would be greatly appreciated.

Cheers,

Kyle

extempore latest from github at https://github.com/digego/extempore/commit/2ce009e

llvm 3.4.1 patched

Linux 3.18.7-v7+

gcc 4.6.3

[Andrew Sorensen]

Hi Kyle,

First off, wonderful to hear that you are trying to get Extempore running on an arm platform.  Just keep in mind that while ARM is theoretically supported, it isn't something that I've tested in a number of years so you are trailblazing here :)  It is something that needs to work though so I'm happy to give you as much support as I can.  So feel free to email me directly if this mailing list topic starts getting long ;) 

First off, I'm assuming that you didn't compile extempore with MCJIT support turned on?  You'll be able to tell by starting up extempore and looking at the log you'll see  "MCJIT  :  YES or NO" depending on whether you did or did not compile in MCJIT support.  If your startup says no, then you'll need to recompile extempore with ./all.bash -DEXT_MCJIT.  You need MCJIT support turned on for ARM.  Incidently MCJIT will  become the default in the not too distant future.

That's step one.   Let us know how you get on after that phase :)

Cheers,

Andrew.

p.s. In a future post, could you also post the ARCH line from the log:  Something like  "ARCH           : x86_64-apple-darwin14.0.0" but obviously from the PI

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

[Andrew Sorensen]

p.s. make sure you do a ./clean.bash before rebuilding ;)

[Kyle Summers]

Hi Andrew,

Thanks for the quick response, and you were spot on re. my not having built with MCJIT support :)

Cleaned and rebuilt with EXT_MCJIT to no apparent effect unless I'm (entirely possible) missing something obvious. I've included below the complete output post rebuild, and comments on what I was trying to produce those results.

Out of time for tonight unfortunately, my progress might be a bit slow as I'm definitely still beginner status in this arena. Happy to be trailblazing, and even more so if it provides any kind of semi useful testing or feedback.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Missing log info from before (oops):

ARCH           : armv7l-unknown-linux-gnueabihf
CPU            : 
ATTRS          : 
MCJIT          : YES
Output Device  : default
Input Device   : 
SampleRate     : 44100
Channels Out   : 2
Channels In    : 0
Frames         : 128
Latency        : 0.0435374 sec

Service/compiler startup and then extempore-connect from emacs, and evaluating my-test-1 from ./examples/core/extempore_lang.xtm results in a crash with the following in the log:

Starting utility process
Trying to connect to 'localhost' on port 7098
New Client Connection 
Successfully connected to remote process

Starting primary process
Trying to connect to 'localhost' on port 7099
New Client Connection 
Successfully connected to remote process
New Client Connection 
Compiled:  my-test-1 >>> [i64,i64]* zone size: 8192 (default)
Aborted

Starting a new session and reconnecting, to execute first the bind-val and then bind-func for circle_area example from the tutorial on benswift.me results in another crash on the bind-func operation again:

...usual preamble...
SetValue:  myPI >>> double

Type Error couldn't resolve types: (r circle_area)  you could try forcing the type of one or more of these symbols

Compiled:  circle_area >>> [double,double]* zone size: 8192 (default)
Aborted

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I'll start to get deeper into it over the next little while, but I've a feeling it'll be a a slightly longer while before I've gotten a handle on what's really going into an operation like this. Not having used gdb since my uni days that might be my starting point aside from some general reading.

If in the meantime any pointers troubleshooting wise come to mind I'll gladly do my best to follow up.

Thanks again,


Kyle

[Ben Swift]

Hey Kyle

Also, just a heads up that Andrew and I have been doing some work recently which isn't quite ready yet, but will help with the arm stuff. I'll announce it on the list when it's ready. 

Cheers,

Ben

[Rilla]

Hey guys, I'm also interested in running extempore on ARM (I'm trying to build it right now in my Raspi 2)

Any updates? 

Thanks!

[digego]

Here are a few things to keep in mind with regards to the pi. 

Just to be clear up front, Extempore is not going to work out of the box on any ARM systems at the moment - particularly 32bit ARM systems.  It *can* work, as I've had it working on 32bit ARM in the past - but it will not work from the current baseline without some hacking/debugging/problem solving.  So if you're still keen, I've added a few preliminary notes below.

Just for a little background, the primary reason that ARM has fallen off the wagon is because we've struggled to move Extempore over from the old LLVM JIT to the new LLVM MCJIT.  This is entirely due to Windows, or more specifically LLVM on Windows - grrrr!.  The end result being that we've had to stick with the old JIT for our default builds - which does not support ARM.

So first off, you'll definitely need to run MCJIT.  Extempore with MCJIT works fine on OSX and Linux out of the DEV branch.  So you'll need to compile extempore from the DEV branch (not MASTER).  We are hoping to switch DEV to MASTER soon, but have a few remaining issues to sort out - (Windows of course).  Should be fine for you to run from DEV though as presumably you're targeting Linux.  You'll know if you are running MCJIT, because when you start Extempore it prints out a message MCJIT : (YES | NO).  

Once you have MCJIT up and running you'll need to make sure that the ARCH looks right - also printed out by Extempore on startup. I'm not 100% sure what the ARCH should be for the PI - you'll need to investigate.  In LLVM speak this is called the target triple, you can google it - it needs to be correct for the specific ARM (presumably 32bit) processor that the PI uses, and is possibly something that you'll need to tweak in the Extempore src. 

There are a few places where we've dropped the ball on 32bit portability (i.e. we have some 64bit assumptions lying around).  Sorry, our bad, and we need to fix this.  There aren't many as we've only introduced them recently (last year or so), but I don't have a 32bit system at the moment, and haven't had time to track them down.  I'm just raising this so you keep this in mind as you're debugging.  Just FYI this 32/64 bit problem is related to XTLang library code, rather than the Extempore executable itself - in other words xtlang code rather than C/C++ code - and also isn't ARM specific, also X86 32bit.

All that said, we definitely do want to support ARM - particularly 32bit ARM, so we will be very happy to help you to get up and running.  Alternatively it's likely that we will get ARM supported out of the box in the not to distant future ... although it might be 12 months out.

Cheers,

Andrew.

 

[Jose Álvarez Rilla]

Hey Andrew, thanks for this thorough response, I will keep you posted on any progress when I have time to tackle this. 

--

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

--

Jose A. Rilla

http://rilla.es