This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Fixed Writer::createInitMemoryFunction to work for wasm64
ClosedPublic

Authored by aardappel on Nov 30 2020, 2:03 PM.

Diff Detail

Event Timeline

aardappel created this revision.Nov 30 2020, 2:03 PM
aardappel requested review of this revision.Nov 30 2020, 2:03 PM

Looks like we don't have a wasm32 test for this?

tlively accepted this revision.Nov 30 2020, 8:44 PM

Hmm, I guess we don't. Would you mind adding one?

This revision is now accepted and ready to land.Nov 30 2020, 8:44 PM

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.

tlively requested changes to this revision.Dec 1 2020, 10:16 AM
This revision now requires changes to proceed.Dec 1 2020, 10:16 AM

Well, these tests are not going to tell us if the generated instructions make any sense, but ok..

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.

aardappel updated this revision to Diff 309329.Dec 3 2020, 12:05 PM

Has new tests that pass, and checked by hand that the one test where the code contents changed passes wasm-validate :)

tlively added inline comments.Dec 3 2020, 1:05 PM
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.

aardappel updated this revision to Diff 309348.Dec 3 2020, 1:13 PM

Simplified tests

tlively accepted this revision.Dec 3 2020, 1:53 PM

LGTM besides those last couple questions!

lld/wasm/Writer.cpp
927

Does this need to conditionally be a i64.atomic.wait?

954

Conditionally i64.atomic.store?

This revision is now accepted and ready to land.Dec 3 2020, 1:53 PM
aardappel added inline comments.Dec 3 2020, 3:07 PM
lld/wasm/Writer.cpp
954

I believe the i32 refers to be value being stored, not the pointer size.

Herald added a project: Restricted Project. · View Herald TranscriptDec 3 2020, 4:21 PM