This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Add Getdescription function for SBInstruction.
AcceptedPublic

Authored by rdhindsa on Sep 3 2021, 10:42 AM.

Details

Reviewers
labath
clayborg
Summary

Add another Getdescription function for SBInstruction.

When trying to print the instruction, existing GetDescription function doesn't have access to Execution Context. Hence, it prints instructions of the following form for the added test case:
libc.so.6[0x3bce1]: movq 0x108(%rsp), %rax

When a target is passed with this new API call, it is able to extract execution context and hence it prints in the following form:
0x7ffff7af6ce1:movq 0x108(%rsp), %rax

Diff Detail

Event Timeline

rdhindsa requested review of this revision.Sep 3 2021, 10:42 AM
rdhindsa created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptSep 3 2021, 10:43 AM
JDevlieghere added inline comments.Sep 3 2021, 12:26 PM
lldb/source/API/SBInstruction.cpp
260

In addition to the LLDB_RECORD_METHOD, you also need the corresponding LLDB_REGISTER_METHOD macro. If you remove the macro, lldb-instr can generate both for you if you pass it the cpp file.

rdhindsa updated this revision to Diff 370660.Sep 3 2021, 1:11 PM
rdhindsa marked an inline comment as done.

Added LLDB_REGISTER_METHOD for GetDescription.

clayborg accepted this revision.Sep 7 2021, 3:13 PM
This revision is now accepted and ready to land.Sep 7 2021, 3:13 PM
labath added a comment.Sep 8 2021, 1:16 AM

I'm not sure what's the exact use case here, but I /think/ that passing just the target part of the execution context will is not sufficient to enable all the disassembler bells and whistles. For example the regular "disassemble" command will also print a "-> " next to the instruction that references the current PC.

Even if that is not required for your use case, I think that a better (more generic) API would be for this function to take a SBExecutionContext argument, and let the user choose how it wants to populate it.

lldb/source/API/SBInstruction.cpp
241–256

It seems like this function could now just delegate to the new version, passing a null/empty target or execution context

Would it be better to make an API that takes an SBExecutionContext? If you knew the frame that held

I'm not sure what's the exact use case here, but I /think/ that passing just the target part of the execution context will is not sufficient to enable all the disassembler bells and whistles. For example the regular "disassemble" command will also print a "-> " next to the instruction that references the current PC.

Even if that is not required for your use case, I think that a better (more generic) API would be for this function to take a SBExecutionContext argument, and let the user choose how it wants to populate it.

I thought the same thing, but then I got to wondering what you should do when the SBExecutionContext you were passed in has a frame with a PC that doesn't point to the instruction you were passed. Is that an error? Does it matter?

I still think the SBExecutionContext is a better choice, and will prevent us from having to add another override later on when we find we need the thread or frame. But we should decide up front whether we want there to be any linkage between the exact ExecutionContext and the instruction you are dumping.