[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