This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Use the selected and host platform to disambiguate between fat binary architectures
ClosedPublic

Authored by JDevlieghere on Mar 29 2022, 2:00 PM.

Details

Summary

Currently we error out if multiple platforms can supports the architectures in a fat binary. For example, on Darwin, almost every architecture supported by the host platform is also supported by the remote-macosx platform. Currently, the only way to disambiguate between the two is to specify the desired architecture.

This patch changes the behavior to account for the selected and host platform. The new algorithm works a follows:

  1. Returns the selected platform if it matches any of the architectures.
  2. Returns the host platform if it matches any of the architectures.
  3. Returns the platform that matches all the architectures.

If none of the above apply, this function returns a default platform. The candidates output argument differentiates between either no platforms supporting the given architecture or multiple platforms supporting the given architecture.

I've added a bunch of unit tests to codify this new behavior.

rdar://90360204

Diff Detail

Event Timeline

JDevlieghere created this revision.Mar 29 2022, 2:00 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 29 2022, 2:00 PM
Herald added subscribers: mgrang, mgorny. · View Herald Transcript
JDevlieghere requested review of this revision.Mar 29 2022, 2:00 PM
JDevlieghere edited the summary of this revision. (Show Details)Mar 29 2022, 3:18 PM

So this will fix LLDB complaining when a binary contains arm64 and x86_64 when debugging on either platform? Great, we ran into this quite a bit lately!

lldb/source/Target/Platform.cpp
1277–1279

Shouldn't we just check if the selected platform matches one architecture here and return the selected platform? Why do all architectures need to match. If I select a platform, and then do "file a.out" and "a.out" contained any number of architectures, it should just use the selected platform, no?

1281–1283

Again, why would we not just return the host platform if one arch matches? same kind of thing as above?

1285–1286

Is this comment out of date? We are iterating through more than one platform here.

1287–1294

What is this doing? Comparing the first entry in candidates to each of the entries and if the name matches, returns the first entry? When would this ever not return true?

1296
1300
aprantl added inline comments.
lldb/include/lldb/Target/Platform.h
102

Would you mind adding a doxygen comment for this? I'm asking because the semantics are not clear to me just from looking at the function signature.

lldb/source/Target/Platform.cpp
1228

would std::unique be more idiomatic?

lldb/unittests/Platform/PlatformTest.cpp
2

super-nit: too few -s :-)

JDevlieghere marked 4 inline comments as done.Mar 29 2022, 3:46 PM
JDevlieghere added inline comments.
lldb/source/Target/Platform.cpp
1277–1279

That's a good question. I did this to mimic what we're doing today, i.e. preferring the platform that matches all architectures in the fat binary.

I was trying to imagine what that could look like. One possible scenario is a fat binary with triples arm64-apple-macosx and arm64-apple-ios. In this case, both the host platform supports arm64-apple-macosx and arm64-apple-ios (https://support.apple.com/guide/app-store/iphone-ipad-apps-mac-apple-silicon-fird2c7092da/mac). And remote-ios supports arm64-apple-ios. If the binary is fat like that, it's more than likely meant to run on macosx, so with this algorithm, we'd do the right thing.

The second reason is that the order of the architectures is pretty arbitrary. Let's consider the arm64-apple-macosx and arm64-apple-ios example again. If we say that we'll pick whichever matches first, then we'll pick the host platform. But if the order was arm64-apple-ios and arm64-apple-macosx then we'll pick remote-ios.

Anyway I'm not married to this approach. I personally think that picking the selected platform is one host matches makes sense. I'm less sure about the host platform.

1281–1283

See my reply above.

1285–1286

Yup, I was uniquing the platforms originally.

1287–1294

This checks that all the platforms are identical. If they're all identical then that means that we have one platform that works for all architectures. This covers case (3) from the summary.

aprantl added inline comments.Mar 29 2022, 3:47 PM
lldb/source/Target/Platform.cpp
1228

Not sure why I didn't see this.

JDevlieghere marked 2 inline comments as done.EditedMar 29 2022, 3:52 PM

So this will fix LLDB complaining when a binary contains arm64 and x86_64 when debugging on either platform? Great, we ran into this quite a bit lately!

Yes, exactly. The issue is was introduced by https://reviews.llvm.org/D113159. Previously, IsHost() would be false for remote-macosx and the OSNAME would expand to ios returning absolutely bogus triples. But my change fixed that, causing the remote-macosx platform to be a real contender, and resulting in an error message:

error: more than one platform supports this executable (host, remote-macosx), specify an architecture to disambiguate
clayborg added inline comments.Mar 29 2022, 3:53 PM
lldb/include/lldb/Target/Platform.h
103
lldb/source/Target/Platform.cpp
1277–1279

I agree, so maybe lets switch to say if the selected platform matches at least one, then it is all good. Will the selected platform ever be the host platform?

1287–1294

Sounds good, just update the comment then and all good.

JDevlieghere added inline comments.Mar 29 2022, 3:55 PM
lldb/source/Target/Platform.cpp
1277–1279

I believe the selected platform is the host platform if you didn't specify it explicitly.

JDevlieghere edited the summary of this revision. (Show Details)

Change the algorithm to pick the selected/host platform if it matches at least one architecture.

clayborg accepted this revision.Mar 29 2022, 4:32 PM

Looks good. One nit that you can choose to fix if desired

lldb/source/Target/Platform.cpp
1229–1230

Move this above line 1227?

This revision is now accepted and ready to land.Mar 29 2022, 4:32 PM
labath accepted this revision.Mar 30 2022, 12:04 AM

Just this morning, I was (again) contemplating the idea of introducing some sort of numeric platform priorities. (We currently have a sort of a ternary system -- exact match, compatible match, no match). That would allow us to express pretty much arbitrary relationships ("I know this binary looks like it could be run on the host, but I _really_ want to run it through my super fancy platform").

Nevertheless, the current implementation and the priorities set within it look reasonable to me.

jingham added inline comments.Mar 30 2022, 10:40 AM
lldb/source/Target/Platform.cpp
1252

Why are you passing process_host_arch here? This is the "selected_platform" so you have no way of knowing a priori that this is the host platform or has the same architecture as the host system. In the old version, this selected platform part of the processing passed {} instead of the process_host_arch, which seems more correct.

jingham added inline comments.Mar 30 2022, 10:42 AM
lldb/source/Target/Platform.cpp
1252

Note, the old code made what seems like the opposite mistake, and DIDN'T pass process_host_arch in the Host Platform section of the code.

JDevlieghere marked an inline comment as done.Mar 30 2022, 10:44 AM
JDevlieghere added inline comments.
lldb/source/Target/Platform.cpp
1252

The process_host_arch argument was added to Platform::IsCompatibleArchitecture for https://reviews.llvm.org/rGc22c7a61b6d9c90d5d4292205c63cd576f4fd05b. You're correct that we don't have a process host arch from where this function is being called. So I could have omitted it, but I decided not to for consistency with Platform::GetPlatformForArchitecture just above.

JDevlieghere added inline comments.Mar 30 2022, 10:46 AM
lldb/source/Target/Platform.cpp
1252

The new code in TargetList.cpp:179 still passes {} to GetPlatformForArchitectures as the process host arch.

Herald added a project: Restricted Project. · View Herald TranscriptMar 30 2022, 3:30 PM