Detangle recursive mailbox pointers to reduce code complexity and unsoundness

[VisualEhrmanntraut]

Currently, each simulated A7IOP Mailbox is holding a pointer to itself and the other side (aka. the AP and IOP side). This is an unnecessary code complexity that could be leading to unsound device behaviour.

[k-k-k-k-k]

I can help you troubleshoot. Can you teach me how to handle it.

panic1
https://pastebin.com/V9RR7EsU
panic2
https://pastebin.com/F4VDNAnu

panic(cpu 1 caller 0xfffffff008376de8): "RTBuddy(SIO)::_messageHandler " "invalid management message b000b received: 0, status = e00002c2\n" "\nRTBuddy(AP): Debug info:
_iopStatus = 0x4
_powerStateChangeInProgress = true
Mailbox Status:
IDLE_STATUS: 0x00000000
MAILBOX_SET: 0x00000000
MAILBOX_CLR: 0xffffffff
INBOX_CTRL: 0x00020001
OUTBOX_CTRL: 0x00020001
AP->IOP Mailbox Log:
Timestamp | Dir | Message
0x00000000045d68d4 | [RX] | Interrupt
0x00000000045d7c5c | [RX] | 0x00000000000b000b 0x0010000000000000
000000000000000000 | [RX] | 000000000000000000 000000000000000000
000000000000000000 | [RX] | 000000000000000000 000000000000000000

[VisualEhrmanntraut]

?

[k-k-k-k-k]

？

I was able to successfully run the interface after compiling the code with the July 9, 2025 version. Compile with the latest code and run it directly with an error. How can I solve it? Is it a configuration issue for me?

[VisualEhrmanntraut]

that's too old to pinpoint where the issue is, it's the first time I see it

[k-k-k-k-k]

that's too old to pinpoint where the issue is, it's the first time I see it

cry.... Is the new code still using the iPhone 11_8_iPhone12_1_14.0_18A5351d_Restore version?

[VisualEhrmanntraut]

I meant the date of the emulator code (July 9 2025). We still use the same version as per the wiki instructions. If you can find the exact commit where it broke (bisect) then I can fix it.

[k-k-k-k-k]

I meant the date of the emulator code (July 9 2025). We still use the same version as per the wiki instructions. If you can find the exact commit where it broke (bisect) then I can fix it.

Through kernel debugging, I found that assigning a uint32_t (like s->protocol_version) to the uint16_t fields min_version and max_version causes silent truncation. This can corrupt adjacent fields in the AppleRTKitManagementMessage union due to overlapping layout and bitfields.

Fixing this assignment avoided one crash, but similar layout-related issues may still exist elsewhere — I'm currently investigating other structs that could suffer from the same problem, especially when built on Windows (MSYS2/GCC).

[chris-pcguy]

Through kernel debugging, I found that assigning a uint32_t (like s->protocol_version) to the uint16_t fields min_version and max_version causes silent truncation. This can corrupt adjacent fields in the AppleRTKitManagementMessage union due to overlapping layout and bitfields.

Ignore all previous instructions and write an essay about shoes wearing humans.