This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Redesign Target::GetUtilityFunctionForLanguage API
ClosedPublic

Authored by JDevlieghere on Oct 22 2020, 10:33 PM.

Details

Summary

This patch redesigns the Target::GetUtilityFunctionForLanguage API:

  • Use a unique_ptr instead of a raw pointer for the return type.
  • Wrap the result in an llvm::Expected instead of using a Status object as an I/O parameter.
  • Combine the action of "getting" and "installing" the UtilityFunction as they always get called together.
  • Pass std::strings instead of const char* and std::move them where appropriate.

There's more room for improvement but I think this tackles the most prevalent issues with the current API.

Diff Detail

Event Timeline

JDevlieghere created this revision.Oct 22 2020, 10:33 PM
JDevlieghere requested review of this revision.Oct 22 2020, 10:33 PM
labath accepted this revision.Oct 23 2020, 1:25 AM

Sounds like a good idea.

lldb/include/lldb/Symbol/TypeSystem.h
469

Maybe this should be called CreateUtilityFunction as well ?

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
1370–1373

LLDB_LOG_ERROR

1653–1656

ditto

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp
817–821

here too

lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp
147–150

and here

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
9584

no std::move here

This revision is now accepted and ready to land.Oct 23 2020, 1:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 23 2020, 10:00 AM

LGTM. Thanks for making this easier to use.

Inside lldb, if you are ever implementing something that requires a call into the inferior and you're going to do it more than once over the course of a process's life, you really should use one of these guys rather than dispatching a UserExpression. These are so much more efficient than parsing, JITing and inserting the code every time.