Crash with the example from the readme

[arturoc]

When running the example from the readme or anything else that uses libfringe like tokio-fibers i'm getting a segmenetation fault. Here's the stacktrace

#0  0x000055555555e5a1 in fringe::arch::imp::init::trampoline_2 ()
    at /home/arturo/.cargo/registry/src/github.com-1ecc6299db9ec823/fringe-1.2.1/src/arch/x86_64.rs:115
#1  0x00007fffffffd420 in ?? ()
#2  0x000055555555e592 in fringe::arch::imp::init::trampoline_1 ()
    at /home/arturo/.cargo/registry/src/github.com-1ecc6299db9ec823/fringe-1.2.1/src/arch/x86_64.rs:60
#3  0x000055555555c420 in ?? () at /checkout/src/libcore/option.rs:157
#4  0x0000000000000000 in ?? ()

[whitequark]

(Not related to actual bug: in the future, please surround stacktraces in ``` ``` when you post them; now this issue is linked back from the first four issues in the repository.)

[arturoc]

ugh sorry, i've just edited it

[whitequark]

Unfortunately GitHub doesn't ever remove these backlinks, hence "in the future".

[arturoc]

i know, don't even know how i forgot to use the code fence, sorry again

[edef1c]

Can you reproduce this with current master? We're fixing a bunch of plumbing issues and unsafety that got into 1.x right now, and I'm working on releasing 2.0.0 soon.

[edef1c]

Okay, can reproduce with the branch I'm working on. Welp.

[edef1c]

After spending a while in confusion, I've figured out what's up:

(rr) x/2i $pc-1
   0x5619a1b72a20 <fringe::arch::imp::init::trampoline_2>:	jmp    0x5619a1b72a22 <fringe::arch::imp::init::trampoline_2+2>
   0x5619a1b72a22 <fringe::arch::imp::init::trampoline_2+2>:	nop

I'm not sure how this jmp is being generated - it's definitely not from our assembly. We add 1 byte to the instruction pointer to skip over this nop, but because of the jmp everything decodes rather differently, producing the segfault:

(rr) x/2i $pc
=> 0x5619a1b72a21 <fringe::arch::imp::init::trampoline_2+1>:	add    %dl,0x102454ff(%rax)
   0x5619a1b72a27 <fringe::arch::imp::init::trampoline_2+7>:	retq   

Still unsure why all the libfringe tests are working given all this..

[edef1c]

The tests are passing because we build them with optimisations, causing rustc to eliminate the extra jmp.
I can either do an awful workaround, or I can wait for this to be fixed in rustc, since it should not be generating code into naked functions, and @eddyb is already working on a rustc patch.

[whitequark]

@edef1c Just add a nopsled there.

[edef1c]

@whitequark already did that, but there's more broken stuff (unwinding doesn't find a landing pad) - though maybe I can solve that with even more nops?
Either way, fixing this in rustc fixes it for all arches, and imo this is broken #[naked] behaviour.