Now that the linker handles table symbols, we can allow the frontend to
produce them.
Depends on D91870.
Differential D92215
[WebAssembly] MC layer writes table symbols to object files wingo on Nov 27 2020, 1:11 AM. Authored by
Details Now that the linker handles table symbols, we can allow the frontend to Depends on D91870.
Diff Detail
Event Timeline
Comment Actions still lgtm
Comment Actions Reword comment
Comment Actions Hi, after this commit our builds of wasi-sdk have broken because wasi-libc's makefile [1] finds an undefined symbol for __indirect_function_table that wasn't in its expected list [2]. Just to check, is this intended? Does the undefined-symbols.txt need an update? [1] https://github.com/WebAssembly/wasi-libc/blob/master/Makefile#L506 Comment Actions My understanding is that __indirect_function_table should not be imported (at least not under normal circumstances) but should be created by the linker at link time. Do you happen to have the failing link command or a link to the build log? Comment Actions Ah yes, that list is a list of undefined symbols in the library/object files. In that case the new symbol *is* expected to exist and wasi-sdk will need to be modified to ignore or handle this new symbol somehow. Probably just ignoring it for now makes sense (so that the Makefile continues to work with new and old versions of llvm). Comment Actions Yeah as @sbc100 says, this is intended -- object files now can have table symbols, and if the compilation unit takes the address of a function or makes an indirect call, it will have a __indirect_function_table symbol. So the expectations need updating; sorry for the bother! Note that this could happen again in the future if/when multiple memory support is added, for memory symbols. Comment Actions Looks like this grep -v would be a good place: https://github.com/WebAssembly/wasi-libc/blob/378fd4b21aab6d390f3a1c1817d53c422ad00a62/Makefile#L452 I've locally changed that to "^__mul\|^__indirect_function_table" and it's been working fine for the past few days. @sbc100, I see that you're a project contributor, would you mind landing that to /wasi-libc and /wasi-sdk? I'm also happy to send a pair of PRs but I don't have my account handy this week. Comment Actions Yes, just send a PR when are you get a chance. I don't think its super urgent since most wasi-libc users I think use using stable llvm releases. Comment Actions Out of interest how did you notice this breakage? Are you integrating ToT llvm with wasi-libc for a specific reason? Comment Actions In an unofficial repo we do frequent builds of Firefox with a ToT clang, motivated by some past releases where we waited until RC1 to start testing and had a bad time. We don't specifically set out to test the wasi bits, but some Firefox builds enable wasm sandboxing, which pulls in that code. I must admit I don't fully understand the interaction between the build systems, we have lost some expertise in that area and I'm mostly just keeping things limping along. Comment Actions Reopening, sadly, due to https://reviews.llvm.org/D95420 and https://github.com/WebAssembly/wasi-libc/pull/228. |
I thought the plan was to include this table symbol in a new TABLE_NUMBER reloc to go along with the TABLE_INDEX reloc? Then each call_indirect could have up to two different relocations.