clayborg added inline comments.
================
Comment at: lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp:561
+ default:
+ LLVM_FALLTHROUGH;
+ case ArchSpec::eCore_arm_arm64: {
----------------
fixathon wrote:
> JDevlieghere wrote:
> > fixathon wrote:
> > > This will default to the ArchSpec::eCore_arm_arm64 case if no matching
> > > ArchSpec is specified. Double-checking if this by intent.
> > 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.
> 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'
> - host+ remote-ios
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?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D113155/new/
https://reviews.llvm.org/D113155
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
