This is an archive of the discontinued LLVM Phabricator instance.

[lldb/Platform] Prepare decouple instance and plugin names
ClosedPublic

Authored by labath on Feb 7 2022, 7:47 AM.

Details

Summary

This patch changes the return value of Platform::GetName() to a StringRef, and
uses the opportunity (compile errors) to change some callsites to use
GetPluginName() instead. The two methods still remain hardwired to return the
same thing, but this will change once the ideas in
https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594 are
implemented.

Diff Detail

Event Timeline

labath created this revision.Feb 7 2022, 7:47 AM
labath requested review of this revision.Feb 7 2022, 7:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 7 2022, 7:47 AM

Returning a StringRef from GetName makes sense, but in the constructor, if you're eventually going to store it, why not pass and std::string in and std::move it into place? Other than that this LGTM, but I'll refrain from accepting so it continues to show up in other's review queue.

labath added a comment.Feb 8 2022, 1:22 AM

The main reason for that is because the platform objects are generally created in a loop (for (factory : plugins) { result = factory(cantMove(name), ...)}), so we can't make use of the move semantics because we don't know which construction will stick.

labath added a comment.Feb 8 2022, 1:25 AM

Well.. technically, I suppose I could make the constructors take a std::string, since at that point we're committed to creating the object, but the CreateInstance functions would still need to take a StringRef -- but the net effect is still one string copy.

JDevlieghere accepted this revision.Feb 8 2022, 9:24 PM

I don't feel super strongly, I was just curious.

This revision is now accepted and ready to land.Feb 8 2022, 9:24 PM

I am fine with this. Only suggestion is to use ConstString still for the m_instance_name since we might compare against this name if we are looking for one with a matching name (instead of std::string).

lldb/include/lldb/Target/Platform.h
889

Do we want to make this a ConstString so finding matching instances is quick and just a pointer compare?

Given the renewed interest in the size of the ConstString pool, I'd like to avoid adding strings there without a good reason. And I don't see any reason why a name-based platform lookup should be on any hot path. A Target object holds a platform pointer, the current platform is a pointer, and anything else that is hot enough should probably hold a pointer instead of a name as well.

clayborg accepted this revision.Feb 10 2022, 11:43 AM

Given the renewed interest in the size of the ConstString pool, I'd like to avoid adding strings there without a good reason. And I don't see any reason why a name-based platform lookup should be on any hot path. A Target object holds a platform pointer, the current platform is a pointer, and anything else that is hot enough should probably hold a pointer instead of a name as well.

As you mention there won't be many of these, so it won't take up much space in the string pool, but I am not adamant that this would need to change.

labath updated this revision to Diff 411366.Feb 25 2022, 3:05 AM

Reduce the scope of the patch to GetName interface changes. Given the direction
of the discourse thread, it seems unlikely that we will be able to determine the
instance name at object creation time.

We will likely need a setter which will be called when the class is associated
with a debugger.

labath retitled this revision from [lldb/Platform] Decouple instance and plugin names to [lldb/Platform] Prepare decouple instance and plugin names.Feb 25 2022, 3:06 AM
labath edited the summary of this revision. (Show Details)
JDevlieghere accepted this revision.Feb 25 2022, 10:19 AM

(Still) LGTM

clayborg accepted this revision.Feb 27 2022, 12:03 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 2 2022, 6:01 AM