Remove the nested switches from the ARMGetSupportedArchitectureAtIndex implementation. I considered a few alternatives, like changing the API (too intrusive) and trying to be clever by manipulating indexes (too hard to maintain). I'm not happy about the remaining amount of duplication, but it seemed like the best tradeoff.
Details
Diff Detail
Event Timeline
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp | ||
---|---|---|
573 | I could put this into a def file if desirable, but right now I'm still undecided whether that's overkill. |
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp | ||
---|---|---|
558 | Totally forgot about that. Thanks for the suggestion. |
Added some follow up comments
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp | ||
---|---|---|
561 | This will default to the ArchSpec::eCore_arm_arm64 case if no matching ArchSpec is specified. Double-checking if this by intent. | |
640 | Could we delete this unreachable return statement? It's tripping up static code checkers since all possible branches already have a return. |
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp | ||
---|---|---|
561 | I'm sure it was intentional when I wrote it, but I can't figure out for which core this would actually make sense. If the test suite passes with returning an empty array here, that works for me. | |
640 | Yes, let's make it an llvm_unreachable (otherwise gcc will complain). |
Added comments
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp | ||
---|---|---|
640 | If we return {} in the default case, and delete this, gcc should not complain since all possible code paths will have a return, is that right? |
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp | ||
---|---|---|
640 | Yes, you're right, it's only a problem for gcc when you explicitly handle every case (see all the instances of llvm_unreachable("Fully covered switch!"); in lldb/llvm). |
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp | ||
---|---|---|
640 | I'll just add a break to the default case to avoid llvm_unreachable(). What's the best way to introduce this change? Can I link it to this diff somehow or a stand-alone new diff? |
Added a comment about a failing test.
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp | ||
---|---|---|
561 | When this is fixed, one test is failing, and I think that might be a problem with the test itself: test_ios in test/API/functionalities/gdb_remote_client/TestPlatformMacOSX.py running on MacOS. File "lvm-project/lldb/test/API/functionalities/gdb_remote_client/TestPlatformMacOSX.py", line 48, in test_ios self.platform_test(host="ios", File "llvm-project/lldb/test/API/functionalities/gdb_remote_client/TestPlatformMacOSX.py", line 44, in platform_test self.assertEqual(platform.GetName(), expected_platform) AssertionError: 'host' != 'remote-ios'
|
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp | ||
---|---|---|
561 | Looks like it might be a problem with the test indeed. The "def qHostInfo(self):" from line 21 is returning a CPU type for the host of "cputype:16777223". This is 0x01000007 which is "x86_64" as the 'qHostInfo' packet uses a decimal encoding. Later when asked about the process with "def qProcessInfo(self):" it returns "cputype:100000c" which is hex encoded with no "0x" prefix and it means "arm64". Not sure if this test is trying to test a remote ios debugging scenario from a desktop machine debugging to a ios device, but if this is the case, both qHostInfo and qProcessInfo should be agreeing on the architecture and using the same thing, which would be "arm64"? These are packets that are usually going to the "debugserver", which is run on a phone. So my guess would be to try and set qHostInfo to have "cputype:16777228" (which is decimal for 0x0100000c) and see if that works. Jonas, does this make sense? |
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp | ||
---|---|---|
561 | No, this is intentional and pretty much the point of this test. There's more details in https://reviews.llvm.org/D121444 but the TL;DR is that this is testing running iPhone and iPad Apps on Apple Silicon Macs. That also explains the default then, which I was pretty sure I added for a reason :-) |
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp | ||
---|---|---|
561 | Gotcha, looks like Slava need to debug this and see why we are getting a invalid core type passed to the GetCompatibleArchs() function in the first place. |
Is this any different from an ArrayRef<const char *>?