[llvm] [WebAssembly] Support multiple `.init_array` fragments when writing Wasm objects (PR #111008)

George Stagg via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 6 06:14:13 PST 2024


================
@@ -1769,6 +1769,11 @@ uint64_t WasmObjectWriter::writeOneObject(MCAssembler &Asm,
       WS.setIndex(InvalidIndex);
       continue;
     }
+    // Contents of .init_array sections are handled elsewhere.
+    if (WS.isDefined() &&
+        WS.getSection().getName().starts_with(".init_array")) {
----------------
georgestagg wrote:

> Should we error out int this maybe? It seems like if somebody had a usage of `p_init` somewhere it would simply not work. How about something like "symbols within .init_array sections are not supported"?

A reasonable argument, but I think it would get in the way.

It seems to me the `p_init` symbol is just a side-effect of this pattern in C, where the real intention is just to add the list of function pointers to the `.init_array` section. We don't actually need to reference `p_init` anywhere, but if we throw an error here we unfortunately break the pattern.

Ultimately what I am interested in is some Rust code that uses a [similar pattern](https://github.com/dtolnay/inventory/blob/bb269d9bf2d464a1c6862aba6222f82c325e7c4b/src/lib.rs#L432-L462). Essentially:

```rust
unsafe extern "C" fn __ctor() {
    [...]
}
#[cfg_attr(link_section = ".init_array")]
static __CTOR: unsafe extern "C" fn() = __ctor;
```

So I would be grateful if we could continue to allow for this use case and not error out, even if the side-effect symbol cannot be referenced.

Another option is to keep the current situation, but it means somehow otherwise handling the `invalid data segment index` error when using `obj2yaml` in the unit test for this PR. I think by avoiding emitting the symbols we are doing no worse than before, and perhaps a little better in that regard.

https://github.com/llvm/llvm-project/pull/111008


More information about the llvm-commits mailing list