Re: Re(5): kernel dump server
Re: Re(5): kernel dump server
- Subject: Re: Re(5): kernel dump server
- From: Derek Kumar <email@hidden>
- Date: Tue, 31 Jan 2006 12:35:49 -0500
Hi Derek,
I submitted rdar://4422761 a couple of days ago, and included an
updated kdp_udp.c which solves this problem. Main issue was that
there was no ARP request code there at all, and now there is. This
also ARPs for the router_ip if that is defined in boot-args (this
capability was mentioned in the code as a future enhancement).
Thanks for filing a radar, I'll take a look. (It's likely that
equivalent changes are awaiting release in this particular case, but
contributions to the kernel are always welcome).
Since it was in the same file, I also updated the code for creating
the dump file name so that it now includes the xnu minor version.
Notes in the code suggest that rdar://3735061 requested this
capability.
Great - as I recall, it was intended that we fix this by changing an
internal submission script to stamp the kernel with the version
number, rather than parsing the existing version string (which is
created from OBJROOT (by config/newvers.pl), which includes the
version number in an internal build environment). However, having the
minor version numbers in crashdump filenames is definitely
convenient. N.B.: You can also use the "showversion" kgmacro, which
examines the magic address 0x501C - that holds a pointer to the
version string (or "strings -" on the crashdump and grep that for the
version pattern as a crude work-around if you don't have gdb handy).
You can use that macro on live connections as well, to determine the
version of the kernel you're connected to so you can find the right
symbols. (An "implementation detail" - that macro is fine on PPC and
live x86 connections, however it doesn't yet work on x86 crashdumps -
the currently released x86 kernel doesn't have crashdump support, so
it's not immediately relevant, but it will be eventually :-)
Derek
P.S.: From a quick look, if you're using this internally, your ARP
request routine would have to change to allow control transfer to the
debugger if a debugger packet arrives; also, the code to check for
the crashdump protocol packets is probably unnecessary in your arp
request routine.
And apropos the comment about size checking, kdp_vm_read() is a
debugger routine that checks for a valid translation for both source
and destination pages in the currently active debugger pmap (virtual
address space), and then does a physical mode copy, so it's a "safe
read". We can get away with assuming the translation remains valid
since the debugger runs with interrupts off on the active cpu, and
the rest of the processors are signaled to spin on the debugger lock
on entry.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden