How do i define data in a specific coff/elf/mach-o section?
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()
.
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 ?
It would be nice to have. I am not sure about the correct api though, as cranelift-simplejit
can't support it.
this would be required to support MacOS in a future version.
Which section do you need to specify to support MacOS?
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.
I can give specifics if needed there (my current llvm based compiler emits objc compatbile classses
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.
this would be required to support MacOS in a future version.
Can you say more about why that is?
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.
Ah, interesting. That'd make sense, I guess, and might well be something we need to address eventually
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.
oooh, good point! Does that mean that currently it's not possible to ship Rust code to iOS in production?
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
thanks!
@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.
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?
so there's two ways to to access the objc api
with objc_* c apis
which you might imagine, are a pain
Last updated: Dec 23 2024 at 12:05 UTC