remoteprocess crate fails to build for ARM

[auscompgeek]

   Compiling remoteprocess v0.1.0 (/home/aucg/py-spy/remoteprocess)
error[E0308]: mismatched types             
   --> remoteprocess/src/linux/libunwind/mod.rs:122:45
    |
122 |                 match get_proc_name(cursor, name.as_mut_ptr(), name.len(), &mut raw_offset) {
    |                                             ^^^^^^^^^^^^^^^^^ expected u8, found i8
    |
    = note: expected type `*mut u8`      
               found type `*mut i8`
      
error[E0308]: mismatched types
   --> remoteprocess/src/linux/libunwind/mod.rs:135:41
    |
135 |             Ok(std::ffi::CStr::from_ptr(name.as_ptr()).to_string_lossy().into_owned())
    |                                         ^^^^^^^^^^^^^ expected u8, found i8
    |
    = note: expected type `*const u8`
               found type `*const i8`

error: aborting due to 2 previous errors

[benfred]

Sorry about breaking this, I hadn't even realized that py-spy worked on arm devices =(.

The code that is failing to compile here wouldn't work on arm even if it did compile, it is very specific to x64_86 - and probably should be disabled for that target.

I'd also like to set it up so that we compile the ARM version as part of the CI process. I think we could either use a hosted arm ci service (like https://docs.shippable.com/platform/tutorial/workflow/run-ci-builds-on-arm/ - or we could cross compile to arm on a linux box (following these steps https://github.com/japaric/rust-cross ).

Do you have any sense of which solution would work better? I have basically no arm experience at all (though I am considering getting a raspberry pi to play around with).

[auscompgeek]

Sorry about breaking this, I hadn't even realized that py-spy worked on arm devices =(.

I'm actually not sure whether it does; I was trying to test it out... but previous versions do build (cross-compiling).

(Edit: I managed to get a build that actually runs on a Raspberry Pi, and it works well!)

[benfred]

Glad to hear that this works on a Raspberry Pi!

I fixed the build so that we don't compile the native unwind code for ARM targets in #119, and added some config to travis ci in #120 so we won't break the ARM build in the future (by cross-compiling against the armv7-unknown-linux-gnueabihf target).