如何在Big Sur和Monterey上构建功能

发布于 2025-01-29 22:43:02 字数 2471 浏览 3 评论 0 原文

在驱动程序扩展开发中,我们面临着一些难题。我们想在蒙特雷建造和调试。这意味着我们需要使用Xcode 13。我们还需要支持大型SUR。不幸的是,我们无法使用在Big Sur上使用的Xcode 13构建DEXT。

我们将 driverkit_deployment_target 设置为19(最低值)。 DEXT在Big Sur上加载良好,但是每当用户客户端将DEXT进程与这样的断言失败崩溃时:

Crashed Thread:        0  Dispatch queue: Root

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
dyld2 mode
abort() called

Thread 0 Crashed:: Dispatch queue: Root
0   libsystem_kernel.dylib          0x0000000104bfb3a4 __pthread_kill + 8
1   libsystem_pthread.dylib         0x0000000104de6844 pthread_kill + 272
2   libsystem_c.dylib               0x0000000104b98f24 abort + 124
3   com.apple.DriverKit             0x00000001048b12b4 __assert_rtn + 92
4   com.apple.DriverKit             0x00000001048b151c OSMetaClassBase::QueueForObject(unsigned long long) (.cold.2) + 44
5   com.apple.DriverKit             0x0000000104893068 OSMetaClassBase::QueueForObject(unsigned long long) + 176
6   com.apple.DriverKit             0x0000000104893780 OSMetaClassBase::Invoke(IORPC) + 412
7   com.apple.DriverKit             0x000000010489425c Server(void*, mach_msg_header_t*, mach_msg_header_t*) + 512
8   com.apple.DriverKit             0x00000001048959c8 uiomachchannel(void*, dispatch_mach_reason_t, dispatch_mach_msg_s*, int) + 156
9   libdispatch.dylib               0x0000000104a43b90 _dispatch_mach_msg_invoke + 476
10  libdispatch.dylib               0x0000000104a313ec _dispatch_lane_serial_drain + 308
11  libdispatch.dylib               0x0000000104a448f4 _dispatch_mach_invoke + 464
12  libdispatch.dylib               0x0000000104a313ec _dispatch_lane_serial_drain + 308
13  libdispatch.dylib               0x0000000104a32154 _dispatch_lane_invoke + 456
14  libdispatch.dylib               0x0000000104a33408 _dispatch_workloop_invoke + 1680
15  libdispatch.dylib               0x0000000104a3c9f0 _dispatch_workloop_worker_thread + 764
16  libsystem_pthread.dylib         0x0000000104de75e0 _pthread_wqthread + 276
17  libsystem_pthread.dylib         0x0000000104dee7fc start_wqthread + 8

我在苹果开发人员论坛,建议似乎是“升级到蒙特雷”,这无济于事。

我无法找到任何有意义的断言消息。我尝试在XNU来源挖掘以找到失败的断言,但没有任何运气。

是否有人能够使用在Big Sur上使用的Xcode 13构建dext?任何关于尝试什么的指针都非常欢迎。

We are facing a bit of a conundrum in our DriverKit extension development. We would like to build and debug on Monterey. This means that we need to use Xcode 13. We also need to support Big Sur. Unfortunately we haven't been able to build a DEXT with Xcode 13 that works on Big Sur.

We are setting the DRIVERKIT_DEPLOYMENT_TARGET to 19 (the lowest possible value). The DEXT loads fine on Big Sur but whenever a user client connects the DEXT process crashes with an assertion failure like this:

Crashed Thread:        0  Dispatch queue: Root

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
dyld2 mode
abort() called

Thread 0 Crashed:: Dispatch queue: Root
0   libsystem_kernel.dylib          0x0000000104bfb3a4 __pthread_kill + 8
1   libsystem_pthread.dylib         0x0000000104de6844 pthread_kill + 272
2   libsystem_c.dylib               0x0000000104b98f24 abort + 124
3   com.apple.DriverKit             0x00000001048b12b4 __assert_rtn + 92
4   com.apple.DriverKit             0x00000001048b151c OSMetaClassBase::QueueForObject(unsigned long long) (.cold.2) + 44
5   com.apple.DriverKit             0x0000000104893068 OSMetaClassBase::QueueForObject(unsigned long long) + 176
6   com.apple.DriverKit             0x0000000104893780 OSMetaClassBase::Invoke(IORPC) + 412
7   com.apple.DriverKit             0x000000010489425c Server(void*, mach_msg_header_t*, mach_msg_header_t*) + 512
8   com.apple.DriverKit             0x00000001048959c8 uiomachchannel(void*, dispatch_mach_reason_t, dispatch_mach_msg_s*, int) + 156
9   libdispatch.dylib               0x0000000104a43b90 _dispatch_mach_msg_invoke + 476
10  libdispatch.dylib               0x0000000104a313ec _dispatch_lane_serial_drain + 308
11  libdispatch.dylib               0x0000000104a448f4 _dispatch_mach_invoke + 464
12  libdispatch.dylib               0x0000000104a313ec _dispatch_lane_serial_drain + 308
13  libdispatch.dylib               0x0000000104a32154 _dispatch_lane_invoke + 456
14  libdispatch.dylib               0x0000000104a33408 _dispatch_workloop_invoke + 1680
15  libdispatch.dylib               0x0000000104a3c9f0 _dispatch_workloop_worker_thread + 764
16  libsystem_pthread.dylib         0x0000000104de75e0 _pthread_wqthread + 276
17  libsystem_pthread.dylib         0x0000000104dee7fc start_wqthread + 8

I've seen a similar problem on the Apple developer forums and the advice seems to be "upgrade to Monterey", which doesn't help much.

I have not been able to locate any meaningful assertion message. I tried digging in the XNU sources to find the failing assert, but did not have any luck.

Has anyone been able to build a DEXT with Xcode 13 that works on Big Sur? Any pointers on what to try are very welcome.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

向地狱狂奔 2025-02-05 22:43:02

这花了我一年以上,但是我终于可以找到了根本原因和可接受的解决方案。

(从我的角度来看,另一个答案中提到的两个不同的dexts完全没有帮助,这是首先使用较新的SDK和Xcode版本的关键原因是Apple缺乏Xcode本身的向后兼容性 - 您 - 您'd仍然必须在Xcode 12上构建大型SUR版本,该版本不会在蒙特雷上运行,更不用说Ventura。)

驱动程序21 SDK的明显原因

,Apple注释了 iouserClient :: ExternalMethod 函数到。 ( queueName(iouserclientqueueexternalmethod))根据文档,此队列以对象的默认队列开始,但当然可以将其设置为另一个队列。

但是,这大概是MacOS 12和更新的情况,因为在较旧的驱动程序SDK和内核源中没有提及该名称的队列。这可以解释为什么当断言失败时,队列查找必须导致非编号指针时发生崩溃的原因。 ( OsmetAclassBase :: QueueForObject 在崩溃堆栈中。)

解决

方法似乎实际上很简单!使用受影响的SDK构建时,请至少在受影响的MacOS版本上明确设置命名的队列。 或 start 的所有实例上进行此操作。

IODispatchQueue* default_queue = nullptr;
kern_return_t res = uc->CopyDispatchQueue(kIOServiceDefaultQueueName, &default_queue);
if (res == KERN_SUCCESS && default_queue != nullptr)
{
    res = uc->SetDispatchQueue(kIOUserClientQueueNameExternalMethod, default_queue);
}
OSSafeReleaseNULL(default_queue);

您需要在 init >仅在受影响的SDK版本上定义,因此您可以使用 #ifdef KiouserClientqueuenameExternalMethod 在构建时间检查是否需要修复。

我添加了只需要在 Init 开始时就需要调用,并为您分类。

It's taken me a year+, but I've finally got around to finding the root cause and an acceptable solution for this behaviour.

(Shipping two different dexts as mentioned in the other answer isn't helpful at all from my point of view, as a key reason for using a newer SDK and Xcode version in the first place is Apple's lack of backwards compatibility for Xcode itself - you'd still have to build the Big Sur version on Xcode 12, which won't run on Monterey let alone Ventura.)

The apparent cause

With the DriverKit 21 SDK, Apple annotated the IOUserClient::ExternalMethod function to run on a dedicated named dispatch queue. (QUEUENAME(IOUserClientQueueExternalMethod)) According to the documentation, this queue starts off as the object's default queue, but can of course be set to another queue.

However, this is presumably only the case on macOS 12 and newer, as there is no reference to a queue with that name in older DriverKit SDKs and kernel sources. That would explain why the crash happens when an assertion fails that a queue lookup must result in a non-null queue pointer. (The OSMetaClassBase::QueueForObject in the crash stacktrace.)

Workaround

The workaround appears to actually be pretty straightforward! When building with an affected SDK, make sure the named queue is explicitly set, at least on affected macOS versions. You need to do this during init or Start on every instance of all IOUserClient subclasses in the dext:

IODispatchQueue* default_queue = nullptr;
kern_return_t res = uc->CopyDispatchQueue(kIOServiceDefaultQueueName, &default_queue);
if (res == KERN_SUCCESS && default_queue != nullptr)
{
    res = uc->SetDispatchQueue(kIOUserClientQueueNameExternalMethod, default_queue);
}
OSSafeReleaseNULL(default_queue);

Note that kIOUserClientQueueNameExternalMethod is only defined on affected SDK versions, so you can use #ifdef kIOUserClientQueueNameExternalMethod to check at build time whether the fix is needed.

I've added a helper function to my open source library of dext and kext helper functions that just needs to be called during init or Start and sorts it out for you.

荒芜了季节 2025-02-05 22:43:02

我们面临同样的问题,Apple建议对蒙特雷和Bigsur进行单独的版本,或者进行两个构建,并根据相应的OS修改安装程序以安装。

We faced the same issue, Apple suggested to do a seperate release for both Monterey and BigSur, or do two builds and modify the installer to install based on the corresponding OS.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文