When resolving absolute addresses for DW_OP_addr or DW_OP_addrx, these are always load addresses rather than file addresses in wasm.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm having some trouble coming up with a good test for this in the absence of a real wasm target. any suggestions appreciated!
What does it mean the"lack of a real wasm target", do you mean a compile target? I don't have the context so I'm guessing clang can't compile *to* wasm currently and that means you can't easily make a reproducer that way.
I wonder if you could build something from C targeting <something not wasm> but which has the DWARF construct you need, then force it to be loaded as if it were a wasm object. Seems like that would trip all sorts of assertions though.
The other way is to hand craft an object file, perhaps using obj2yaml? Though I don't know if that will let you define the DWARF in a nice readable way, or whether you'd have to put it in as binary data. (this sort of thing is a bit out of my wheel house)
And if you mean there's no wasm runtime to load the object file into to actually run it - ignore what I just said :)
I'm not sure there is a way around that. Short of building the file and hacking up enough of it so that lldb saw eCore_wasm32.
I thought maybe you could use a corefile instead but A: I don't know that wasm supports those and B: that we support what it produces either.
You're missing context for the diff https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface (though I could swear it was there before).
Can you explain the reasoning for the rule, is there a wasm DWARF doc that explains it? Maybe it is just common sense given what wasm is, but I've not used it myself.
lldb/unittests/Expression/DWARFExpressionTest.cpp | ||
---|---|---|
435 | There are two target && target->GetArchitecture().GetCore() == ArchSpec::eCore_wasm32 checks, does this cover both? (will probably be obvious once the diff has context) |
Sorry for the missing context, I forgot that's manual!
The most complete description of wasm DWARF is here: https://yurydelendik.github.io/webassembly-dwarf/ (via https://github.com/WebAssembly/tool-conventions/blob/main/Debugging.md). But it doesn't really discuss the details of this rule.
In essence, the reason is that wasm file sections aren't mapped into wasm memory. A wasm program can therefore not access any data from file sections, and hence no address will ever point to the file. Consequently for varibles that have statically known addresses encoded as DW_OP_addr, these addresses should be interpreted as load addresses, not file addresses.
In essence, the reason is that wasm file sections aren't mapped into wasm memory. A wasm program can therefore not access any data from file sections, and hence no address will ever point to the file.
This is enough for me, please add some version of that as a comment in both places where you check for wasm.
lldb/unittests/Expression/DWARFExpressionTest.cpp | ||
---|---|---|
435 | I think the answer to this is no, you need to add a test for DW_OP_GNU_addr_index? Not sure. |
There are two target && target->GetArchitecture().GetCore() == ArchSpec::eCore_wasm32 checks, does this cover both?
(will probably be obvious once the diff has context)