Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support parsing symbols from the linking section for wasm objects #471

Open
bjorn3 opened this issue Oct 3, 2022 · 6 comments
Open

Support parsing symbols from the linking section for wasm objects #471

bjorn3 opened this issue Oct 3, 2022 · 6 comments

Comments

@bjorn3
Copy link
Contributor

bjorn3 commented Oct 3, 2022

In case of wasm object files there is no export section. Instead all exported symbols are defined in the "linking" section. This is necessary for rust-lang/rust#97485. See https://github.com/WebAssembly/tool-conventions/blob/main/Linking.md for the full specification.

@philipc
Copy link
Contributor

philipc commented Mar 31, 2023

Is this blocked on wasmparser support? Can you provide a wasm file that I can use for testing this?

@bjorn3
Copy link
Contributor Author

bjorn3 commented Mar 31, 2023

cat > foo.rs <<EOF
#[no_mangle]
extern "C" fn foo() -> u8 { bar() }
fn bar() -> u8 { *FOO.lock().unwrap() }
static FOO: std::sync::Mutex<u8> = std::sync::Mutex::new(42);
EOF
rustc foo.rs --target wasm32-unknown-unknown --crate-type lib --emit obj

produces foo.o.gz (gzip compressed without a tar archive as github didn't accept a gzipped tarball despite saying that .tgz is accepted as file extension)

For reference:

$ wasm-objdump -h foo.o
foo.o:  file format wasm 0x1

Sections:

     Type start=0x0000000e end=0x00000046 (size=0x00000038) count: 9
   Import start=0x0000004c end=0x0000027d (size=0x00000231) count: 10
 Function start=0x00000283 end=0x0000029f (size=0x0000001c) count: 27
     Elem start=0x000002a5 end=0x000002af (size=0x0000000a) count: 1
DataCount start=0x000002b5 end=0x000002b6 (size=0x00000001) count: 30
     Code start=0x000002bc end=0x000012de (size=0x00001022) count: 27
     Data start=0x000012e4 end=0x00001675 (size=0x00000391) count: 30
   Custom start=0x0000167b end=0x000023b5 (size=0x00000d3a) "linking"
   Custom start=0x000023bb end=0x000025ce (size=0x00000213) "reloc.CODE"
   Custom start=0x000025d4 end=0x00002631 (size=0x0000005d) "reloc.DATA"
   Custom start=0x00002637 end=0x00002654 (size=0x0000001d) "target_features"

@bjorn3
Copy link
Contributor Author

bjorn3 commented Mar 31, 2023

This can be implemented without wasmparser changes.

@philipc
Copy link
Contributor

philipc commented Apr 4, 2023

This can be implemented without wasmparser changes.

I didn't see anything in wasmparser that can parse these sections. Are you recommending we implement our own parsing? If we're going to use wasmparser for parsing wasm then I expect parsing of the linking section to be implemented in wasmparser.

@bjorn3
Copy link
Contributor Author

bjorn3 commented Apr 4, 2023

Wasmparser indeed doesn't have any code to parse this AFAIK. Adding the code to wasmparser would avoid code duplication with anyone else who needs it, but it would be possible to put the parse code for the linking custom section in object too. Wasmparser gives a raw byte slice as content for custom sections.

@philipc
Copy link
Contributor

philipc commented Apr 4, 2023

If someone has to write the code, they may as well do it in wasmparser, so let's wait for someone to do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants