This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Allow plugins to extend DWARF expression parsing for vendor extensions
ClosedPublic

Authored by pfaffe on Nov 2 2022, 5:41 AM.

Details

Summary

Parsing DWARF expressions currently does not support DW_OPs that are vendor
extensions. With this change expression parsing calls into SymbolFileDWARF for
unknown opcodes, which is the semantically "closest" plugin that we have right
now. Plugins can then extend SymbolFileDWARF to add support for vendor
extensions.

Diff Detail

Event Timeline

pfaffe created this revision.Nov 2 2022, 5:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 2 2022, 5:41 AM
pfaffe requested review of this revision.Nov 2 2022, 5:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 2 2022, 5:41 AM

I'm missing some context here I think.

I assume the use case is that, for example, we don't want to be adding a bunch of WASM specific DWARF operations to the generic operations. If those can live in a WASM (the "vendor") plugin then we know where to look and they can use any vendor specific knowledge to do their job.

Along the right lines? I think I saw some talk about this on a previous diff but don't remember now.

lldb/include/lldb/Target/Platform.h
959 ↗(On Diff #472588)

stray change

lldb/source/Expression/DWARFExpressionList.cpp
93

I'm not sure that m_dwarf_cu is always non null. It might be in practice but for example one use ends up in UpdateValueTypeFromLocationDescription which checks that it is not null before use.

Maybe it is reasonable to assume it is never null (and if it is and you have the time, a preparatory patch to make it a ref would be great).

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
342

Seems like clang-format missed a bit here.

lldb/unittests/Expression/DWARFExpressionTest.cpp
571

Is there not 3 more arguments to read off here? The 0x00 0x00 0x00 from above.

751–765

Can you dedeupe this section of both tests? Appears to be the same.

DavidSpickett added inline comments.Nov 2 2022, 7:53 AM
lldb/unittests/Expression/DWARFExpressionTest.cpp
719

I know it's just a test but is there an EM_WASM you could use?

Maybe lldb doesn't understand that name yet so it makes no difference anyway.

pfaffe added a comment.Nov 2 2022, 9:30 AM

Yes, you got the context right! Although technically speaking this change isn't limited to wasm, plugins can implement any vendor extension on top of this change.

lldb/source/Expression/DWARFExpressionList.cpp
93

I think it's worth checking in general. Before https://reviews.llvm.org/D125509, the DWARFExpression used to be assiciated with its dwarf_cu. I was considering bringing that back, what do you think?

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
342

Curious, I would have assumed the linter at the very least would have caught that.

lldb/unittests/Expression/DWARFExpressionTest.cpp
571

No, the second argument to this opcode is of type uint32_t, the zeros are the last three bytes of that. Should I maybe use a simpler/fake opcode? Might be dangerous if that fake opcode ever got occupied/implemented.

DavidSpickett added inline comments.Nov 2 2022, 9:37 AM
lldb/source/Expression/DWARFExpressionList.cpp
93

I think you should ask the author of that change :)

On the surface that change makes sense but I'm no expert. If that's the case then you'll just want to sprinkle some if not nullptr around wherever you use it.

(nullptrs are fine if there is a reason to use the null state)

lldb/unittests/Expression/DWARFExpressionTest.cpp
571

It was the comment misleading me:

// Called with "arguments" 0x03, 0x04, 0x00, 0x00, 0x00

So I'm thinking there is an operation that is called with arguments 3, 4, 0, 0, 0.

Just reword the comment and it'll be fine.

pfaffe updated this revision to Diff 472863.Nov 3 2022, 12:59 AM
pfaffe marked 4 inline comments as done.

Address comments.

pfaffe added inline comments.Nov 3 2022, 1:01 AM
lldb/unittests/Expression/DWARFExpressionTest.cpp
719

There's no EM_WASM, in fact wasm has it's own non-ELF container. I picked x86 ELF because ELFYAML has the DWARF section which is convenient, WASMYAML sadly does not.

pfaffe marked an inline comment as not done.Nov 7 2022, 7:46 AM
pfaffe updated this revision to Diff 475399.Nov 15 2022, 2:48 AM

Stray change.

pfaffe marked an inline comment as done.Nov 15 2022, 2:50 AM

What was the decision on m_dwarf_cu possibly being nullptr? We at least want asserts in paths where we assume it'll not be null.

Beyond that this seems fine but I'm not really into DWARF, @labath any comments?

Seems like quite a cheap fallback to add, and my assumption is that we don't find many unknown opcodes in general use.

I threaded dwarf_cu down to where it's really used and added the necessary check, so if it is nullptr, the fallback will be skipped.

Looks ok, module some inline comments.

lldb/source/Expression/DWARFExpression.cpp
2573

For other methods, we just have the dwo class override the method and call the main file instead.

lldb/source/Expression/DWARFExpressionList.cpp
93

DWARF expressions are used in contexts where there is no DWARF unit to speak of. Our use of DWARF expressions in PDB (the motivation behind that patch) is questionable at best, but DWARF expressions are also used in eh_frame for instance, which I think would be a good reason to keep DWARFExpression DWARFUnit-free. OTOH, some of the DWARF operations cannot be evaluated without a DWARFUnit, so.... I don't know...

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
45

and then you don't need to make this public.

pfaffe updated this revision to Diff 477099.Nov 22 2022, 1:21 AM
pfaffe marked 2 inline comments as done.

Override new functions in DWOs.

labath accepted this revision.Nov 22 2022, 5:36 AM
labath added inline comments.
lldb/source/Expression/DWARFExpression.cpp
41–44

I think these are not needed anymore.

This revision is now accepted and ready to land.Nov 22 2022, 5:36 AM