Intended to fix: https://github.com/WebAssembly/memory64/issues/12
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I believe there is some coverage of createInitMemoryFunction in the tests.. although maybe not in a very useful/readable way.
Any test that checks for __wasm_init_memory is likely testing the output of this function:
$ git grep __wasm_init_memory lld/test/wasm/ lld/test/wasm/data-segment-merging.ll:; PASSIVE-MERGE-NEXT: Name: __wasm_init_memory lld/test/wasm/data-segment-merging.ll:; PASSIVE-SEPARATE-NEXT: Name: __wasm_init_memory lld/test/wasm/data-segments.ll:; PASSIVE-NEXT: Name: __wasm_init_memory lld/test/wasm/tls.s:# Skip __wasm_call_ctors and __wasm_init_memory
Because the disassembly in objdump is not yet good enough to give good results on executables (it works OK for object files I think), its quite hard to write wasm-ld tests that verify the instructions themselves so we end up with tests that check the raw bytes of the function bodies.
For example in lld/test/wasm/data-segments.ll we have:
; PASSIVE-LABEL: - Type: CODE ; PASSIVE-NEXT: Functions: ; PASSIVE-NEXT: - Index: 0 ; PASSIVE-NEXT: Locals: [] ; PASSIVE-NEXT: Body: 0B ; PASSIVE-NEXT: - Index: 1 ; PASSIVE-NEXT: Locals: [] ; PASSIVE-NEXT: Body: 41B4D60041004101FE480200044041B4D6004101427FFE0102001A054180084100410DFC08000041900841004114FC08010041B4D6004102FE17020041B4D600417FFE0002001A0BFC0900FC09010B
Here the second body corresponds to __wasm_init_memory I believe.
Admittedly is not great.. but I think it counts a test for now until we can get objdump -d working a bit better. (I have some ideas about next steps for that if you'd like to work on it).
Oh right, I forgot about those crazy unreadable tests. Sam is totally right. For now adding new RUN and CHECK lines to those tests should be sufficient.
Well, these tests are not going to tell us if the generated instructions make any sense, but ok..
Indeed, that would requiring fixing objdump -d to work with executables.
I had a PR I was working on to make this work by creating dummy symbols for each function in the object file reader (in the case where no symbol table was found). That way every function (even in a stripped executable) would always appear to have some kind of symbol name to the disassembler.
Has new tests that pass, and checked by hand that the one test where the code contents changed passes wasm-validate :)
lld/test/wasm/data-segment-merging.ll | ||
---|---|---|
150 | If you replaced --check-prefix=PASSIVE-MERGE above with --check-prefixes=PASSIVE-MERGE,PASSIVE-MERGE32 and if you used --check-prefixes=PASSIVE-MERGE,PASSIVE-MERGE64 in this new run line, then you could avoid duplicating all of the context here by using PASSIVE-MERGE for everything that is shared and the *32 and *64 prefixes for only the lines that are different. Same for the PASSIVE-SEPARATE checks. |
lld/wasm/Writer.cpp | ||
---|---|---|
954 | I believe the i32 refers to be value being stored, not the pointer size. |
If you replaced --check-prefix=PASSIVE-MERGE above with --check-prefixes=PASSIVE-MERGE,PASSIVE-MERGE32 and if you used --check-prefixes=PASSIVE-MERGE,PASSIVE-MERGE64 in this new run line, then you could avoid duplicating all of the context here by using PASSIVE-MERGE for everything that is shared and the *32 and *64 prefixes for only the lines that are different. Same for the PASSIVE-SEPARATE checks.