[llvm-bugs] [Bug 34392] New: llvm-nm yields incorrect result for Webassembly objects

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=34392

            Bug ID: 34392
           Summary: llvm-nm yields incorrect result for Webassembly
                    objects
           Product: tools
           Version: 5.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-nm
          Assignee: unassignedbugs at nondot.org
          Reporter: mvogelsang at rocketmail.com
                CC: dschuff at google.com, llvm-bugs at lists.llvm.org

Created attachment 19067
  --> https://bugs.llvm.org/attachment.cgi?id=19067&action=edit
test.c

llvm-nm is able to process binary wasm object files and produce well-formatted
results, but the results aren't sensible or useful. I'll outline the expected
behaviour and actual behaviour.

If we have a file `test.c` with the contents
'''
char first[0xF];
char second[0xFF];
char third[0x9];
char fourth[0xA];
'''

and compile it to ARM using a clang that is set to target
`aarch64-unknown-linux-gnu` with the command `$CC -c test.c -o armtest.o` we
can look at the GNU nm output with `nm -P armtest.o` with the following
results.
'''
$d.0 n 0000000000000000 
first C 000000000000000f 000000000000000f
fourth C 000000000000000a 000000000000000a
second C 00000000000000ff 00000000000000ff
third C 0000000000000009 0000000000000009
'''

llvm-nm yields a similar enough result with `llvm-nm -P armtest.o`
'''
$d.0 n 0 0
first C f 0
fourth C a 0
second C ff 0
third C 9 0
'''

Now, we can compile test.c to wasm using a clang set to target
`wasm32-unknown-unknown-wasm` with the command `$CC -c test.c -o wasmtest.o`.
GNU nm, of course, just errors if you try to run it on wasmtest.o. However
`llvm-nm -P wasmtest.o` yields the following.
'''
first D 0 0
fourth D 3 0
second D 1 0
third D 2 0
'''

It kinda just spits out the symbols with a number that indicates the relative
declaration order.
It is worthwhile to take a look at the wasm-dis of wasmtest.o.
'''
(module
 (global $global$0 i32 (i32.const 0))
 (global $global$1 i32 (i32.const 16))
 (global $global$2 i32 (i32.const 271))
 (global $global$3 i32 (i32.const 280))
 (table 0 anyfunc)
 (memory $0 1)
 (data (i32.const 0)
"\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00")
 (export "first" (global $global$0))
 (export "second" (global $global$1))
 (export "third" (global $global$2))
 (export "fourth" (global $global$3))
 ;; custom section "linking", size 15
)
'''

Notice, lines 2-5 seem to indicate that the information necessary to determine
symbol values/sizes and offsets is available in wasmtest.o, the file just isn't
getting processed correctly. Somehow, for each symbol we're getting the 'x' out
of it's '$global$x'. 

test.c, armtest.o, wasmtest.o, and the wasm-dis are attached. 

Sorry to preemptively ping you on this Derek. I couldn't file this under
llvm-nm and something wasm related, so I figured I should at least tag someone
on the wasm team to make you all aware. 

GHC's build system actually relies on using nm at one point. Our current
workaround is to compile with -flto and parse the llvm-dis of the necessary
object files.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170831/8fc3dbca/attachment.html>