site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi Derek, the ARP request routine will allow the control transfer, in the same way that takes place during the dump itself. The "flag_panic_dump_in_progress" flag is already set and the routine kdp_arp_request (line 1277) calls kdp_poll which will cause the transfer (test around line 678) if a packet is received. Hello, kdp_poll() doesn't actually perform a control transfer if a debugger packet arrives in the course of a crashdump - it merely clears some globals via abort_panic_transfer() and returns to the caller, which would be your ARP request routine in this case. It is the caller's responsibility to then cause an exit from kdp_panic_dump(), which will then switch to the debugger, i.e. kdp_connection_wait(), if certain conditions are met. In your implementation, you'd address this by checking for a return of -2 from your arp request routine, and then branching to the panic_dump_exit label. But it's a minor point. An issue with the way this is done is that the original debugger packet is discarded, so it will only be the next debugger connection retry that makes it through. The other testing etc I deliberately left alone as much as possible - my thought way to make the minimal set of changes necessary, rather than do a more extensive change which would be harder to integrate (or even accept). Also, some changes might have ramifications elsewhere and I wanted that risk to be as small as possible. For example, I considered and then rejected the temptation to allow a port-number specification as part of the _panicd_ip address, the reason being that it would require a change to the parser for boot-args (16 character limit, this arg could be 22). So, even though there are some redundancies, they were deliberate in order to make the changes easier to review and evaluate. A port number for the crashdump server could certainly be a separate boot-arg (or the parser could be changed to allow IP:port notation, if that's what you meant); I'd have to check if the server allows you to specify the port it would bind to, but if not, that can be changed. It's probable that we will utilize only a portion of your patch in this instance (since the lack of ARP resolution will be addressed in a future update, along with the issue that can cause the polled mode packet send/receive routines to bind to the wrong interface in some cases), but it's great to see contributions - keep them coming! Something else that I wanted to note was that a feature that was asked for last WWDC, the ability to examine the live, running kernel on the same machine, has been in use internally for quite some time, and should be made available externally in a forthcoming tools release. Also, it's possible to do both crashdumps and kernel debugging over a firewire transport, which can be pretty useful in some cases. I'll check to see if those tools can/have been made available externally. Derek _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com