Hello all,
currently our code treats platform name more-or-less as a unique
identifier (e.g. Platform::Find returns at most one platform instance
--the first one it finds).
This is why I was surprised that the "platform select" CLI command
always creates a new instance of the given platform, even if the
platform of a given name already exists. This is because
Platform::Create does not search the existing platform list before
creating a new one. This might sound reasonable at first, but for
example the Platform::Create overload which takes an ArchSpec first
tries to look for a compatible platforms among the existing ones before
creating a new one.
For this reason, I am tempted to call this a bug and fix the name-taking
Create overload. This change passes the test suite, except for a single
test, which now gets confused because some information gets leaked from
one test to another. (although our coverage of the Platform class in the
tests is fairly weak)
However, this test got me thinking. It happens to use the the SB way of
manipulating platforms, and "creates" a new instance as
lldb.SBPlatform("remote-linux"). For this kind of a command, it would be
reasonable/expected to create a new instance, were it not for the fact
that this platform would be very tricky to access from the command line,
and even through some APIs -- SBDebugger::CreateTarget takes a platform
_name_.
So, which one is it? Should we always have at most one instance of each
platform, or are multiple instances ok?
cheers,
pl
PS: In case you're wondering about how I run into this, I was trying to
create a pre-configured platform instance in (e.g.) an lldbinit file,
without making it the default. That way it would get automatically
selected when the user opens an executable of the appropriate type. This
actually works, *except* for the case when the user selects the platform
manually. That's because in that case, we would create an
empty/unpopulated platform, and it would be the one being selected
because it was the /current/ platform.
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
