[StackIR] Support source maps and DWARF with StackIR #6564
Conversation
| @@ -2303,7 +2303,7 @@ Contains section .debug_info (851 bytes) | |||
| Contains section .debug_loc (1073 bytes) | |||
| Contains section .debug_ranges (88 bytes) | |||
| Contains section .debug_abbrev (333 bytes) | |||
| Contains section .debug_line (2682 bytes) | |||
| Contains section .debug_line (2642 bytes) | |||
There was a problem hiding this comment.
Is this expected and accounted for?
There was a problem hiding this comment.
I believe so, yes. StackIR saves a few bytes here and there, which allows encoded offsets to be a bit shorter in some cases. Any increase in size (in this or any other field) would have been very suspicious, however. A large decrease would also have been odd.
I did also run llvm-dwarfdump --validate on the output and it is equally valid as before this PR (which is, 99% valid but for one known pre-existing minor issue).
|
Oh yes, sorry. |
|
Thanks, then I simplified the test now to have autogenerated CHECKs, since the checks are identical between StackIR and BinaryenIR (and without two parsers, there is just one output for BinaryenIR). |
Helping #6509, this fixes debugging support for StackIR, which makes it more
possible to use StackIR in more places.
The fix is basically just to pass around some more state, and then to call the
parent with "please write debug info" at the correct times, mirroring the
similar calls in
BinaryenIRWriter.The relevant Emscripten tests pass, and the source map test modified
here produces identical output in StackIR and non-StackIR modes.
Remove
--new-wat-parserin the test here - @tlively we don't need thatanymore do we?