This is an archive of the discontinued LLVM Phabricator instance.

[wasm] Always treat DWARF expression addresses as load addresses
ClosedPublic

Authored by pfaffe on Oct 11 2022, 6:28 AM.

Details

Summary

When resolving absolute addresses for DW_OP_addr or DW_OP_addrx, these are always load addresses rather than file addresses in wasm.

Diff Detail

Event Timeline

pfaffe created this revision.Oct 11 2022, 6:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 11 2022, 6:28 AM
pfaffe requested review of this revision.Oct 11 2022, 6:28 AM

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.

pfaffe updated this revision to Diff 468136.Oct 17 2022, 1:49 AM

Managed to add a unit test for the DW_OP_addr path!

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.

pfaffe updated this revision to Diff 471484.Oct 28 2022, 3:59 AM

Full context with arcanist

pfaffe updated this revision to Diff 471485.Oct 28 2022, 4:02 AM

Add comments.

pfaffe updated this revision to Diff 471486.Oct 28 2022, 4:03 AM

Bring back lost changes...

DavidSpickett added inline comments.Oct 28 2022, 4:26 AM
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.

pfaffe updated this revision to Diff 471543.Oct 28 2022, 7:09 AM

Add unittest for DW_OP_addrx as well.

DavidSpickett accepted this revision.Oct 28 2022, 7:39 AM

LGTM, thanks!

This revision is now accepted and ready to land.Oct 28 2022, 7:39 AM