summaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
diff options
context:
space:
mode:
authorDaniel Bertalan <dani@danielbertalan.dev>2025-04-18 18:36:54 +0200
committerGitHub <noreply@github.com>2025-04-18 18:36:54 +0200
commitbc48b3f8b812c755c5e9c42d6b970a9c1b496578 (patch)
tree52b9b2f8a835f5604553f3a67fa0267c3516e086 /lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
parentf4a47b4003b6cfbdd445615b044f0911d99a0e44 (diff)
[lld][WebAssembly] Fix spurious signature mismatch under LTO (#136197)
When generating C++ vtables, Clang declares virtual functions as `void(void)` when their signature is not known (e.g.parameter types are forward-declared). As WASM type checks imports, this would conflict with the real definition during linking. Commit 59f959ff introduced a workaround for this by deferring signature assignment until a definition or direct call is seen. When performing LTO, LLD first scans the bitcode files and creates `DefinedFunction` symbol table entries for their contents. After LTO codegen, they are replaced with `UndefinedFunction`s (so that the definitions will be pulled in from the native LTO-d files when they are added). At this point, if a function is only referenced in bitcode, its signature remains `nullptr`. From here, it should have behaved like in the non-LTO case: the first direct call sets the signature. However, as the `isCalledDirectly` flag was set to true, the missing signature was filled in by the type of the first reference to the function, which could be a `void(void)` vtable entry, which would then conflict with the real definition. This commit sets `isCalledDirectly` to false so that the signature will only be populated when a direct call is found. See godotengine/godot#104497 and emscripten-core/emscripten#10831
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp')
0 files changed, 0 insertions, 0 deletions