Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Kevin Watters
    @kevinw
    hmm, stuck on faerie stuff..looks like the resulting executable has _start instead of "start"
    Dan Gohman
    @sunfishcode
    @kevinw I have a faerie version of simple-jit in a branch in the same repo: https://github.com/sunfishcode/simplejit-demo/tree/faerie
    @kevinw Are you defining "start" yourself, or relying on the standard libraries to provide the entry point?
    Kevin Watters
    @kevinw
    @sunfishcode ah, thanks for your help—got as far as BinaryFormat::Macho => unimplemented!("macho relocations") in cretonne/lib/faerie/src/container.rs :)
    Dan Gohman
    @sunfishcode
    Ah, it ought
    to be straightforward to implement the macho forms; they ought to be similar to the elf ones
    Kevin Watters
    @kevinw
    yeah looking now
    Kevin Watters
    @kevinw
    not sure I'm capable yet of finding the right matches here...still have some learning to do with regards to terminology (GOT, PLT)
    Dan Gohman
    @sunfishcode
    I can take a look in a few minutes here.
    Dan Gohman
    @sunfishcode
    I don't have a machine where I can test this handy, but here's a preliminary patch: sunfishcode/cretonne@1d76dbf
    Kevin Watters
    @kevinw
    @sunfishcode looks very close, we're just missing Reloc::X86PLTRel4
    Kevin Watters
    @kevinw
    as a guess I used X86_64_RELOC_UNSIGNED
    and got
    computer:compiler-faerie kevin$ cargo run && gcc -o test test.o && ./test
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
    Running target/debug/toy
    hello world
    so we're good!
    for the smallest possible test! thanks for your help :)
    Dan Gohman
    @sunfishcode
    Ok, cool!
    I'm not a macho expert, and the documentation I found in a few minutes of poking around is telling me that it doesn't want explicit PLT relocations
    So I think the real fix here is to teach codegen that, so it doesn't use X86PLTRel4 on macho
    But I can follow up on that.
    Kevin Watters
    @kevinw
    okay—glad we could at least get that far!
    Dan Gohman
    @sunfishcode
    @kevinw I now have a more complete fix here: https://github.com/sunfishcode/cretonne/tree/macho-relocations
    Lachlan Sneff
    @lachlansneff
    cretonne/cretonne#363
    Lachlan Sneff
    @lachlansneff
    @sunfishcode Do you know what's going on here? https://travis-ci.org/cretonne/cretonne/jobs/391915031
    Pat Hickey
    @pchickey
    @lachlansneff I think that test is checking that heap accesses get legalized in a certain way, and you just changed the way that worked, so you'll have to go and fix the tests as well
    Lachlan Sneff
    @lachlansneff
    Ah, that makes sense
    Lachlan Sneff
    @lachlansneff
    There we go, tested successfully on my machine. Took about 30 minutes to run all the tests
    Lachlan Sneff
    @lachlansneff
    Finally, the ci has completed
    Kevin Watters
    @kevinw
    @sunfishcode looks great, thanks so much for followin gup
    Kevin Watters
    @kevinw
    a general note: i'm learning cretonne, and having trouble with one bit of the docs—looking at seal_block(), and it says "Declares that all the predecessors of this block are known." what's a predecessor?
    also:
    my experiment is making a compiler that's heavily multithreaded from the get go, and i'm having trouble seeing which parts of the code are meant to be used from multiple threads. are there examples of using for example, multiple Contexts across different threads?
    Lachlan Sneff
    @lachlansneff
    The general design is that you can compile each context in a separate thread
    (And each context generally corresponds to a function)
    And then, you link everything together at the end with relocations
    Kevin Watters
    @kevinw
    that's the "finalize" bits?
    Lachlan Sneff
    @lachlansneff
    Oh, not sure about the module interface
    My use of cretonne doesn't use that
    Kevin Watters
    @kevinw
    ok, that helps though
    Lachlan Sneff
    @lachlansneff
    I think that the module interface is not multithreaded rn
    You'll likely have to write a new backend
    Kevin Watters
    @kevinw
    i can poke around the nebulet sources to learn more i'm sure—that's your project right?
    Lachlan Sneff
    @lachlansneff
    Yep!
    Just looking around the module lib, it looks like it's designed to act as a single unit.
    So, if you want to use that, you'll probably just compile that on a single thread
    If you want to multithread, you gotta implement stuff yourself
    Kevin Watters
    @kevinw
    cool
    I could be wrong, @sunfishcode would know.