Don't substract 1 from end_addr in line program writing

[bjorn3]

Fixes #2173

[ggreif]

Thanks for the quick fix! Let me come up with a regression test for it! (Will take a few hours, but there is no haste...) DONE!

[ggreif]

PR: bjorn3#1

Note: the test added is ignored, due to the usual lack of tools on CI for running it. Try

cargo test translate -- --ignored

After reverting 053757f, the above fails.

[yurydelendik]

Let's try that. In the past it was always an issue, e.g. I had the following in the dwarf-to-json library:

https://github.com/yurydelendik/dwarf-to-json/blob/d9c6f665f67da3f862a36d88b86eb488ca4bbc4d/src/dwarf.rs#L488-L500

Can you check if we have similar case here?

I'm skeptical about test having hardcoded address. We can keep it though for now with note that it relies on cranelift generator, so the address will be changed when generation changes.

[yurydelendik]

maybe add a comment similar to what we have in the test?

[ggreif]

I'm skeptical about test having hardcoded address. We can keep it though for now with note just it relies on cranelift generator, so the address will be justed when generation changes.

Yeah, right, I was thinking of this too. But it shouldn't be very bad, since

• short code is more resistant of CG changes
• this part of CG should be mature and rather slowly-moving by now (fingers crossed)
• the test is ignored, so it won't run in CI
• the intent is clear, so easy to fix if a CG change would touch this.

Also the FileCheck Rust library seems to be missing advanced features like captures and evaluation. I don't even know whether the LLVM tool proper provides those.

So I suggest to leave it like this for now, and if it causes headaches, just drop it. Better ideas?

[ggreif]

This is a copy&pasted function which could be refactored. I didn't do it, because this is test-only code. If somebody objects, I'm happy to fix.

[bjorn3]

Filecheck does have captures:

wasmtime/cranelift/filetests/filetests/regalloc/coalesce.clif

Line 30 in a7f7c23

; check: brnz v0, $(splitEdge=$BB)

[ggreif]

Filecheck does have captures

That's cool, but I cannot see the ability to do $(expr <var> + 1) or such.

[ggreif]

Let's try that. In the past it was always an issue, e.g. I had the following in the dwarf-to-json library:

https://github.com/yurydelendik/dwarf-to-json/blob/d9c6f665f67da3f862a36d88b86eb488ca4bbc4d/src/dwarf.rs#L488-L500

Can you check if we have similar case here?

I can't see how that could be. The DWARF5 standard is pretty much unambiguous in its wording (p151):

end_sequence:
A boolean indicating that the current address is that of the first byte after the end of a sequence of target machine instructions. end_sequence terminates a sequence of lines; therefore other information in the same row is not meaningful.

[yurydelendik]

Thank you for the patch