[lld][WebAssembly] Prefer objdump -d over obj2yaml for tests. NFC

[sbc100]

Summary

Now that we have https://reviews.llvm.org/D105539 we can
use objdump -d to actually check for instruction sequences
rather than binary blobs.

This is just an example of how to do that we should followup
with a wider ranging conversion of existing tests.

[dschuff]

I guess depending on what the test is looking for, objdump might also be able to replace obj2yaml for non-code-section stuff too. At least data section maybe?

[sbc100]

In D106897#2908076, @dschuff wrote:

I guess depending on what the test is looking for, objdump might also be able to replace obj2yaml for non-code-section stuff too. At least data section maybe?

I think other sections are less readable with objdump. e.g.:

$ llvm-objdump -s ...
....
Contents of section DATA:
 0000 01004180 080b1003 00000004 0000002a  ..A............*
 0010 0000002b 000000    

The problem here is that the section header is also displayed not just the actual data, so its less clear I think.

[dschuff]

! In D106897#2908207, @sbc100 wrote:
Contents of section DATA:

0000 01004180 080b1003 00000004 0000002a  ..A............*
0010 0000002b 000000

The problem here is that the section header is also displayed not just the actual data, so its less clear I think.

Oh, interesting. So obj2yaml doesn't show the section header. Do you know if ELF objdump shows the header too? If not, maybe we should make wasm objdump match

[dschuff]

but anyway this change is fine.
I guess one advantage of using objdump over obj2yaml when they are equivalent might be if we can get the whole test in one tool invocation instead of 2.

[sbc100]

In D106897#2908772, @dschuff wrote:

but anyway this change is fine.
I guess one advantage of using objdump over obj2yaml when they are equivalent might be if we can get the whole test in one tool invocation instead of 2.

I think the difference is that ELF sections don't have headers... I think all the headers are stored centrally for ELF.

[sbc100]

In D106897#2908810, @sbc100 wrote:

In D106897#2908772, @dschuff wrote:

but anyway this change is fine.
I guess one advantage of using objdump over obj2yaml when they are equivalent might be if we can get the whole test in one tool invocation instead of 2.

I think the difference is that ELF sections don't have headers... I think all the headers are stored centrally for ELF.

Most wasm sections contain all kind of structured data... its not clear exactly what bytes should be considered payload, (think data sections with maybe individual data segments within in it... in that case you can data and metadata interspersed).

[dschuff]

I'd say from the llvm-objdump perspective (which only thinks of sections and not anything more finegrained other than instructions), anything other than the section header would be payload, including subsections etc. Unless we want llvm-objdump to be even smarter, a la wasm-objdump. I'm not sure if there's precedent for that in other formats or not.

[sbc100]

In D106897#2908921, @dschuff wrote:

I'd say from the llvm-objdump perspective (which only thinks of sections and not anything more finegrained other than instructions), anything other than the section header would be payload, including subsections etc. Unless we want llvm-objdump to be even smarter, a la wasm-objdump. I'm not sure if there's precedent for that in other formats or not.

Even if we do that it doesn't really help our use case here since the DATA section still has some seeming random bytes that describe the segments, which follow the section header and precede any actual user data.

[wingo]

Neat :) LGTM as well of course.

An idle thought -- I think it may be in the spirit of llvm-objdump to allow llvm-objdump --disassemble-all to produce some kind of structured representation for non-code sections, perhaps in the grammar accepted for .S files. As it is, it tries to parse the bodies of non-code sections as bytecode, which obviously produces garbage and may run into similar asserts as in https://bugs.llvm.org/show_bug.cgi?id=50957. That would allow you to use one tool for more things.

lld/test/wasm/startstop.ll

 ; RUN: llc -filetype=obj -o %t.o %s
 ; RUN: llc -filetype=obj %p/Inputs/explicit-section.ll -o %t2.o
 ; RUN: wasm-ld --export=get_start --export=get_end --export=foo --export=var1 %t.o %t2.o -o %t.wasm
 ; RUN: obj2yaml %t.wasm | FileCheck %s
+; RUN: llvm-objdump -d --no-show-raw-insn %t.wasm | FileCheck %s --check-prefix=ASM
 
 target triple = "wasm32-unknown-unknown"
 
 @foo = global i32 3, section "mysection", align 4
 @bar = global i32 4, section "mysection", align 4
 
 @__start_mysection = external global i8*
 @__stop_mysection = external global i8*
 
 define i8** @get_start() {
   ret i8** @__start_mysection
 }
 
 define i8** @get_end() {
   ret i8** @__stop_mysection
 }
 
 define void @_start()  {
 entry:
   ret void
 }
-; CHECK:        - Type:            CODE
-; CHECK-NEXT:     Functions:
-; CHECK-NEXT:       - Index:           0
-; CHECK-NEXT:         Locals:          []
-; CHECK-NEXT:         Body:            4180888080000B
-; CHECK-NEXT:       - Index:           1
-; CHECK-NEXT:         Locals:          []
-; CHECK-NEXT:         Body:            4190888080000B
-; CHECK-NEXT:       - Index:           2
-; CHECK-NEXT:         Locals:          []
-; CHECK-NEXT:         Body:            0B
-; CHECK-NEXT:   - Type:            DATA
+
+;      CHECK:   - Type:            DATA
 ; CHECK-NEXT:     Segments:
 ; CHECK-NEXT:       - SectionOffset:   7
 ; CHECK-NEXT:         InitFlags:       0
 ; CHECK-NEXT:         Offset:
 ; CHECK-NEXT:           Opcode:          I32_CONST
 ; CHECK-NEXT:           Value:           1024
 ; CHECK-NEXT:         Content:         03000000040000002A0000002B000000
-; CHECK-NEXT:   - Type:            CUSTOM
-; CHECK-NEXT:     Name:            name
-; CHECK-NEXT:     FunctionNames:
-; CHECK-NEXT:       - Index:           0
-; CHECK-NEXT:         Name:            get_start
-; CHECK-NEXT:       - Index:           1
-; CHECK-NEXT:         Name:            get_end
-; CHECK-NEXT:       - Index:           2
-; CHECK-NEXT:         Name:            _start
+
+;       ASM: 00000001 <get_start>:
+; ASM-EMPTY:
+;  ASM-NEXT:        3:     i32.const 1024
+;  ASM-NEXT:        9:     end
+
+;       ASM: 0000000a <get_end>:
+; ASM-EMPTY:
+;  ASM-NEXT:        c:     i32.const 1040
+;  ASM-NEXT:       12:     end