Stream: cranelift

Topic: sections

Carlo Kok (Apr 27 2020 at 06:45):

How do i define data in a specific coff/elf/mach-o section?

bjorn3 (Apr 27 2020 at 09:21):

At this point there is no way to get specify a target section when using .define_data(). When using either cranelift-object or cranelift-faerie, you will have to manually define it on the object::write::Object cq faerie::Artifact after you called .finish().

Carlo Kok (Apr 29 2020 at 10:12):

Is there a plan to do this? or would be of interest (once I'm proficient enough with cranelift and rust) to do a pull request at some point in the future ?

bjorn3 (Apr 29 2020 at 10:49):

It would be nice to have. I am not sure about the correct api though, as cranelift-simplejit can't support it.

Carlo Kok (Apr 29 2020 at 13:34):

this would be required to support MacOS in a future version.

Philip Craig (Apr 30 2020 at 00:50):

Which section do you need to specify to support MacOS?

Carlo Kok (Apr 30 2020 at 05:08):

On macos, you tend to need to interact with objc. Now that can be done through APIs but the cleanest way is through mach-o sections/segments. The objc runtime then finds the classes and class references and hooks everything up.

Carlo Kok (Apr 30 2020 at 05:09):

I can give specifics if needed there (my current llvm based compiler emits objc compatbile classses

Philip Craig (Apr 30 2020 at 06:22):

Ok I don't know anything about objc. If it's only extra metadata that needs to be put in those sections (and not the code/data itself), then you may be able to add it via the object APIs after module::finish.

Till Schneidereit (Apr 30 2020 at 12:18):

this would be required to support MacOS in a future version.

Can you say more about why that is?

bjorn3 (Apr 30 2020 at 12:31):

Maybe he was talking about the fact that apple is slowly making LLVM bitcode mandatory to distribute apps in the app store? This is stored in a certain section of the object file.

Till Schneidereit (Apr 30 2020 at 12:39):

Ah, interesting. That'd make sense, I guess, and might well be something we need to address eventually

bjorn3 (Apr 30 2020 at 12:43):

rustc_codegen_llvm also has this problem, as it uses a different LLVM version. Currently it just generates a dummy bitcode and clang argument section to please the linker for iOS.

Till Schneidereit (Apr 30 2020 at 12:47):

oooh, good point! Does that mean that currently it's not possible to ship Rust code to iOS in production?

bjorn3 (Apr 30 2020 at 12:54):

https://github.com/getditto/rust-bitcode has a script to recompile rustc against the apple version of LLVM.

See also https://github.com/rust-lang/rust/issues/35968

Till Schneidereit (Apr 30 2020 at 13:02):

thanks!

Carlo Kok (Apr 30 2020 at 16:13):

@Till Schneidereit what I meant was that for Objc classes (Which on OSX are kind of a requirement to do anything on the OS) you need to emit data with pointers to functions and other data in special sections the runtime knows.

Till Schneidereit (Apr 30 2020 at 16:22):

Ah, so you didn't mean a future version of macOS, but a future version of Wasmtime, got it!

I think I still don't fully understand, though—would having this data in the correct format give us good ObjC bindings that people could use to create and interact with Wasm instances, as opposed to them having to go through the C API?

Carlo Kok (Apr 30 2020 at 16:28):

so there's two ways to to access the objc api

Carlo Kok (Apr 30 2020 at 16:28):

with objc_* c apis

Carlo Kok (Apr 30 2020 at 16:28):

which you might imagine, are a pain

Last updated: Nov 22 2024 at 16:03 UTC