StanfordPL / stoke

STOKE: A stochastic superoptimizer and program synthesizer
http://stoke.stanford.edu
Apache License 2.0
735 stars 75 forks source link

Go support #847

Open ainar-g opened 8 years ago

ainar-g commented 8 years ago

This is the continuation of issue #27 from the original repo. Issues I've encountered this time, with stoke version 6a0f6e9b:

  1. Issues with files in bins that have spaces in names. In my case (this program compiled with Go 1.5.1) stoke extract generates among others these files:

    type__eq_[256]struct { schedtick uint32; schedwhen int64; syscalltick uint32; syscallwhen int64 }.s
    type__eq_[61]struct { Size uint32; Mallocs uint64; Frees uint64 }.s
    type__eq_[67]struct { size uint32; nmalloc uint64; nfree uint64 }.s
    type__eq_struct { schedtick uint32; schedwhen int64; syscalltick uint32; syscallwhen int64 }.s
    type__eq_struct { Size uint32; Mallocs uint64; Frees uint64 }.s
    type__eq_struct { size uint32; nmalloc uint64; nfree uint64 }.s

    stoke testcase will then fail with

    Error reading value: typeeq_struct { schedtick uint32; schedwhen int64; syscalltick uint32; syscallwhen int64 }.s -- Label on line one differs from name given in file: type__eq_struct { schedtick uint32; schedwhen int64; syscalltick uint32; syscallwhen int64 } vs. typeeq_struct

    After removing those, I am able to proceed.

  2. The "deadlock" I've mentioned in the original issue is still there. Putting println("start") and println("finish") in the program's main shows that stoke testcase runs it, but after that it gets stuck and seemingly does nothing. popcnt.tc is created, but it's empty. strace shows that it reads all files in bins and then waits for something:

    <...>
    stat("bins/runtime_f64equal.s", {st_mode=S_IFREG|0664, st_size=1135, ...}) = 0
    open("bins/runtime_f64equal.s", O_RDONLY) = 5
    read(5, "  .text\n  .globl runtime_f64equa"..., 8191) = 1135
    read(5, "", 8191)                       = 0
    close(5)                                = 0
    getdents(4, /* 0 entries */, 32768)     = 0
    close(4)                                = 0
    rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f3c1aee7d40}, {SIG_DFL, [], 0}, 8) = 0
    rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f3c1aee7d40}, {SIG_DFL, [], 0}, 8) = 0
    rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
    clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffd86a444a0) = 15471
    wait4(15471, 
bchurchill commented 8 years ago

Thank you for your report. We'll definitely keep track of these issues, but we don't have the ability to work on these at the moment. If you can patch 'stoke extract' for the first one so that will Go programs will behave more nicely, we're all for it. If you can provide steps to reproduce the second issue that will make it more likely that we (or someone else) can debug it at some point.

Depending on how committed you are, there are other ways to build testcases. It's easy to get the validator to do this via symbolic execution, and we also have a generator for random testcases that works well if you're doing only simple things (it's not so good with data structures). It's also possible to build them by hand.

ainar-g commented 8 years ago

Sorry for the delay. Here is a gist that reproduces the second issue:

https://gist.github.com/ainar-g/c43446f60b3dded12e62

Go installation instructions can be found on golang.org. As for the first issue, I could look into that, but it doesn't bother me that much.

pwaller commented 7 years ago

I'm having another problem trying with Go 1.7 binaries:

stoke extract fails on the vast majority of functions with error messages of the form:

Could not encode 'movq   %fs:0xfffffffffffffff8,%rcx' within 9 bytes
bchurchill commented 7 years ago

Does Go have a stack protector feature? That could cause this to be generated. If so, turning it off might be a workaround. I don't understand enough about how segment registers work in 64bit mode to suggest a real solution at the moment.

On Nov 26, 2016 23:39, "Peter Waller" notifications@github.com wrote:

I'm having another problem trying with Go 1.7 binaries:

stoke extract fails on the vast majority of functions with error messages of the form:

Could not encode 'movq %fs:0xfffffffffffffff8,%rcx' within 9 bytes

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/StanfordPL/stoke/issues/847#issuecomment-263090229, or mute the thread https://github.com/notifications/unsubscribe-auth/AAnG6bzxC-NO8GE-vjuyECaXYI8aEZ6xks5rCLUcgaJpZM4HevoR .

eloj commented 7 years ago

Stacks are implemented quite differently in Go compared to C, since Go will (for go-routines at least) switch stacks from under a routine if it needs more space.