This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Move toString helpers to BinaryFormat. NFC.
ClosedPublic

Authored by sbc100 on May 14 2018, 1:44 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

sbc100 created this revision.May 14 2018, 1:44 PM
sbc100 retitled this revision from [WebAssembly] Move toString helpers to BinaryFormat to [WebAssembly] Move toString helpers to BinaryFormat. NFC..May 14 2018, 1:45 PM
sbc100 retitled this revision from [WebAssembly] Move toString helpers to BinaryFormat. NFC. to [WebAssembly] Move toString helpers to BinaryFormat..May 14 2018, 1:46 PM
sbc100 added a reviewer: ncw.
sbc100 retitled this revision from [WebAssembly] Move toString helpers to BinaryFormat. to [WebAssembly] Move toString helpers to BinaryFormat. NFC..
This revision was not accepted when it landed; it landed in state Needs Review.May 14 2018, 3:46 PM
This revision was automatically updated to reflect the committed changes.
vsk added a subscriber: vsk.May 16 2018, 11:00 AM

Hi,

I'm seeing a few link failures due to this commit (I think):

Undefined symbols for architecture x86_64:
  "llvm::wasm::toString(llvm::wasm::WasmSymbolType)", referenced from:
      llvm::object::WasmSymbol::print(llvm::raw_ostream&) const in RandomAccessVisitorTest.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This affects the llvm-rc binary and some unit tests. I'm not sure why others aren't seeing the same build break -- possibly this is due to my building with modules. Here's a candidate fix:

diff --git a/tools/llvm-rc/CMakeLists.txt b/tools/llvm-rc/CMakeLists.txt
index 4cadc176691..175de768bf7 100644
--- a/tools/llvm-rc/CMakeLists.txt
+++ b/tools/llvm-rc/CMakeLists.txt
@@ -1,6 +1,7 @@
 set(LLVM_LINK_COMPONENTS
   Option
   Support
+  BinaryFormat
   )
 
 set(LLVM_TARGET_DEFINITIONS Opts.td)
diff --git a/unittests/DebugInfo/CodeView/CMakeLists.txt b/unittests/DebugInfo/CodeView/CMakeLists.txt
index 70a7b8af144..ea3adc6f2ea 100644
--- a/unittests/DebugInfo/CodeView/CMakeLists.txt
+++ b/unittests/DebugInfo/CodeView/CMakeLists.txt
@@ -1,5 +1,6 @@
 set(LLVM_LINK_COMPONENTS
   DebugInfoCodeView
+  BinaryFormat
   )
 
 add_llvm_unittest(DebugInfoCodeViewTests

Could you please take a look?

In D46847#1101688, @vsk wrote:

Hi,

I'm seeing a few link failures due to this commit (I think):

Undefined symbols for architecture x86_64:
  "llvm::wasm::toString(llvm::wasm::WasmSymbolType)", referenced from:
      llvm::object::WasmSymbol::print(llvm::raw_ostream&) const in RandomAccessVisitorTest.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This affects the llvm-rc binary and some unit tests. I'm not sure why others aren't seeing the same build break -- possibly this is due to my building with modules. Here's a candidate fix:

diff --git a/tools/llvm-rc/CMakeLists.txt b/tools/llvm-rc/CMakeLists.txt
index 4cadc176691..175de768bf7 100644
--- a/tools/llvm-rc/CMakeLists.txt
+++ b/tools/llvm-rc/CMakeLists.txt
@@ -1,6 +1,7 @@
 set(LLVM_LINK_COMPONENTS
   Option
   Support
+  BinaryFormat
   )
 
 set(LLVM_TARGET_DEFINITIONS Opts.td)
diff --git a/unittests/DebugInfo/CodeView/CMakeLists.txt b/unittests/DebugInfo/CodeView/CMakeLists.txt
index 70a7b8af144..ea3adc6f2ea 100644
--- a/unittests/DebugInfo/CodeView/CMakeLists.txt
+++ b/unittests/DebugInfo/CodeView/CMakeLists.txt
@@ -1,5 +1,6 @@
 set(LLVM_LINK_COMPONENTS
   DebugInfoCodeView
+  BinaryFormat
   )
 
 add_llvm_unittest(DebugInfoCodeViewTests

Could you please take a look?

Yes, that looks like this change. I'll take a look. I wonder why I didn't see those errors.

I can't reproduce those failures locally. I also build with BUILD_SHARED_LIBS=ON so I would expect to see the same errors as you.

Can you see how RandomAccessVisitorTest.cpp makes use of BinaryFormat/Wasm.h? Your fix looks find to me though. Is it just those two targets that fail?

vsk added a comment.May 16 2018, 1:42 PM

I can't reproduce those failures locally. I also build with BUILD_SHARED_LIBS=ON so I would expect to see the same errors as you.

I don't use that option, but I do use LLVM_ENABLE_MODULES=On.

Can you see how RandomAccessVisitorTest.cpp makes use of BinaryFormat/Wasm.h?

In the .o, I see:

__ZNSt3__110unique_ptrIN12_GLOBAL__N_123RandomAccessVisitorTest15GlobalTestStateENS_14default_deleteIS3_EEED1Ev:
...
000000000000032a        movq    __ZNK4llvm6object10WasmSymbol4dumpEv(%rdi), %r14 ## llvm::object::WasmSymbol::dump() const

For some reason, the unit test's GlobalTestState deleter needs to store a function pointer to WasmSymbol::dump? If I remove "LLVM_DUMP_METHOD" from the definition, it no longer appears in the .o. I think something strange with attribute((used)) is happening, and I don't understand why. The only use of this symbol in the IR is in the magic @llvm.used global.

Your fix looks find to me though. Is it just those two targets that fail?

These are the only two targets which fail to build as a part of 'check-llvm'. Do you want to dig any deeper into this, or should I just land the build fix?

In D46847#1101983, @vsk wrote:

I can't reproduce those failures locally. I also build with BUILD_SHARED_LIBS=ON so I would expect to see the same errors as you.

I don't use that option, but I do use LLVM_ENABLE_MODULES=On.

Can you see how RandomAccessVisitorTest.cpp makes use of BinaryFormat/Wasm.h?

In the .o, I see:

__ZNSt3__110unique_ptrIN12_GLOBAL__N_123RandomAccessVisitorTest15GlobalTestStateENS_14default_deleteIS3_EEED1Ev:
...
000000000000032a        movq    __ZNK4llvm6object10WasmSymbol4dumpEv(%rdi), %r14 ## llvm::object::WasmSymbol::dump() const

For some reason, the unit test's GlobalTestState deleter needs to store a function pointer to WasmSymbol::dump? If I remove "LLVM_DUMP_METHOD" from the definition, it no longer appears in the .o. I think something strange with attribute((used)) is happening, and I don't understand why. The only use of this symbol in the IR is in the magic @llvm.used global.

Your fix looks find to me though. Is it just those two targets that fail?

These are the only two targets which fail to build as a part of 'check-llvm'. Do you want to dig any deeper into this, or should I just land the build fix?

Yes, please land the fix. Its a logical extension to the fixes I already made. I'd try with LLVM_ENABLE_MODULES out of curiosity too.

vsk added a comment.May 16 2018, 3:23 PM

After rebasing on r332530, the fix I suggested no longer works. I'll take another look.