Support parsing symbols from the linking section for wasm objects

[bjorn3]

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]

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

[bjorn3]

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]

This can be implemented without wasmparser changes.

[philipc]

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]

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]

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]

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]

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]

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

[philipc]

I've started implementing this.

[philipc]

Can someone who wants this please review #766.