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

bjorn3 · 2022-10-03T16:13:35Z

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 · 2023-03-31T03:14:39Z

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

bjorn3 · 2023-03-31T16:22:20Z

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 · 2023-03-31T16:25:42Z

This can be implemented without wasmparser changes.

philipc · 2023-04-04T05:37:07Z

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 · 2023-04-04T06:21:22Z

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 · 2023-04-04T06:57:58Z

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

andylizi · 2025-02-09T07:23:06Z

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

I think this is now added in bytecodealliance/wasm-tools#1348

tgross35 · 2025-04-19T19:20:16Z

Does this explain why wasm symbols sometimes show up with no name? For a small demo:

// rustc a.rs --emit=obj --target=wasm32-unknown-unknown --crate-type=lib -Cdebuginfo=0

extern "C" { fn some_undef(); }

#[unsafe(no_mangle)]
extern "C" fn somefunc() {
    unsafe { some_undef() };
}

llvm-nm correctly shows the two symbols but using object, somefunc shows up as an empty name.

$ llvm-nm a.o
         U some_undef
00000001 T somefunc
$ ./util a.o
Symbol { name: "env", address: 0, size: 0, kind: File, section: None, scope: Dynamic, weak: false, flags: None }
Symbol { name: "__linear_memory", address: 0, size: 0, kind: Data, section: Undefined, scope: Dynamic, weak: false, flags: None }
Symbol { name: "some_undef", address: 0, size: 0, kind: Text, section: Undefined, scope: Dynamic, weak: false, flags: None }
Symbol { name: "", address: 0, size: 0, kind: File, section: None, scope: Compilation, weak: false, flags: None }
Symbol { name: "", address: 2, size: 9, kind: Text, section: Section(SectionIndex(10)), scope: Compilation, weak: false, flags: None }

Util for reference

fn main() {
    let path = env::args().nth(1).unwrap();
    let data = fs::read(path).expect("reading file failed");
    let obj = object::File::parse(&*data).expect("failed to parse object");
    for sym in obj.symbols() {
        println!("{sym:?}");
    }
}

philipc · 2025-04-20T05:41:28Z

Yes, that's a Wasm object file so this issue needs to be fixed to properly support it.

philipc · 2025-04-21T12:28:47Z

I've started implementing this.

philipc · 2025-04-22T06:47:01Z

Can someone who wants this please review #766.

philipc · 2025-04-25T06:33:30Z

Symbol names should be correct now. There is further work to do:

determine the section and address for non-code symbols
handle other linking subsections, in particular relocations, but also segments and comdat sections might be useful
not directly related to the linking section, but we should stop returning synthetic symbols for imports and exports. We should only return symbols that actually exist.

bjorn3 mentioned this issue Oct 3, 2022

Full support for parsing the linking section bytecodealliance/wasm-tools#785

Closed

bjorn3 mentioned this issue Apr 2, 2023

Fixes LTO + build-std + Oz failed to resolve undefined symbols rust-lang/rust#109821

Closed

5 tasks

philipc added the help wanted label Apr 4, 2023

philipc mentioned this issue Apr 22, 2025

read/wasm: support symbol table in linking section #766

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

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

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

Comments