This is an archive of the discontinued LLVM Phabricator instance.

[lldb][NFCI] Remove use of ConstString from UnixSignals
ClosedPublic

Authored by bulbazord on Aug 28 2023, 12:15 PM.

Details

Summary

The majority of UnixSignals strings are static in the sense that they do
not change. The overwhelming majority of these strings are string
literals. Using ConstString to manage their lifetime does not make
sense. The only exception to this is one of the subclasses of
UnixSignals, for which I have created a StringSet local to that file
which will guarantee the lifetimes of these StringRefs.

As for the other benefits of ConstString, string uniqueness is not a
concern (as many of them are already string literals) and comparing
signal names and aliases should not be a hot path.

Diff Detail

Event Timeline

bulbazord created this revision.Aug 28 2023, 12:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 28 2023, 12:15 PM
bulbazord requested review of this revision.Aug 28 2023, 12:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 28 2023, 12:15 PM
This revision is now accepted and ready to land.Aug 29 2023, 12:48 AM
fdeazeve added a comment.EditedAug 29 2023, 4:52 AM

I am slightly wary of making this a global set without any kind of thread safe mechanism, as I (naively, not really knowing how this class is used) would expect us to be able to instantiate multiple servers and have them be accessed concurrently. As such, it makes more sense to have each server own its set of strings.

Have we considered having UnixSignals be the one to extend the lifetime of strings? It seems that UnixSignals is the one storing the StringRefs and therefore requiring extended lifetime. I couldn't figure out if there is any other advantage to this vs the other suggestion.

lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
49

Is there a strong motivation for making this a global static, instead of a private member of PlatformRemoteGDBServer?
My assumption here is that we only ever have one PlatformRemoteGDBServer active at any given time, otherwise (if concurrent servers now or in the future) the global approach is not thread safe.

I am slightly wary of making this a global set without any kind of thread safe mechanism, as I (naively, not really knowing how this class is used) would expect us to be able to instantiate multiple servers and have them be accessed concurrently. As such, it makes more sense to have each server own its set of strings.

Have we considered having UnixSignals be the one to extend the lifetime of strings? It seems that UnixSignals is the one storing the StringRefs and therefore requiring extended lifetime. I couldn't figure out if there is any other advantage to this vs the other suggestion.

Right, that's a fair concern I think. The reason I chose to make it not the job of UnixSignals is that the majority of these strings are string literals. I think having the one instance where the strings are not literals somewhere in a data section should be responsible for guaranteeing the lifetimes of these strings. I did not want to put them in the ConstString string pool because I don't think that string pool needs any more strings in it than already exist there.

That being said, you suggested the StringSet be a private member variable of PlatformRemoteGDBServer. This may work, but I wasn't sure what the lifecycle of PlatformRemoteGDBServer objects were. Perhaps it exists for a time but is destroyed sometime later. At that point, UnixSignals will hold onto some dangling references. I decided to make it a global object to guarantee its lifetime independent of any PlatformRemoteGDBServer instance. I don't mind wrapping it in a concurrent structure to guarantee thread safety though.

I decided to make it a global object to guarantee its lifetime independent of any PlatformRemoteGDBServer instance. I don't mind wrapping it in a concurrent structure to guarantee thread safety though.

At that point we would pretty much be re-implementing the notion of a ConstString but with a separate pool, right?

By the way, feel free to disregard this discussion, I just wanted to make sure we are aware that we lost one safety we had before.

I decided to make it a global object to guarantee its lifetime independent of any PlatformRemoteGDBServer instance. I don't mind wrapping it in a concurrent structure to guarantee thread safety though.

At that point we would pretty much be re-implementing the notion of a ConstString but with a separate pool, right?

By the way, feel free to disregard this discussion, I just wanted to make sure we are aware that we lost one safety we had before.

Yep, that's basically correct. It would be a ConstString but a separate pool. I also don't want to disregard your point, I think it's a good one. LLDB already has enough thread-safety issues as-is...

bulbazord updated this revision to Diff 554504.Aug 29 2023, 3:02 PM

Protect StringSet with a mutex

ping! (in the interest of clearing Phabricator reviews soon)

fdeazeve accepted this revision.Sep 14 2023, 4:22 AM

LGTM!

This revision was landed with ongoing or failed builds.Sep 14 2023, 10:21 AM
This revision was automatically updated to reflect the committed changes.