Re: remote debugging with gdb on 10.6.2
Re: remote debugging with gdb on 10.6.2
- Subject: Re: remote debugging with gdb on 10.6.2
- From: mogambo <email@hidden>
- Date: Mon, 23 Nov 2009 22:19:35 -0800
Thanks, Brian. I made some progress, but I am still having problems.
I tried boot-args 0x144 (although with boot-args 0xd44 I did have _panicd_ip set as welll). The most important I was misisng was NMI the machine with power button. I had used remote debugging with freebsd in my previous job. I don't remember having to do anything special like that.
I am debugging a file system driver, which I am able to load successfully. I created symbols at kextload time and copied to the debugger machine earlier. I used -arch x86_64 as the debugger and debugee are both running 64-bit 10.6. I was able to connect to the debugee in the gdb. With add-symbol-file, I added the kext symbols, but get warnings:
Reading symbols from /path/to/com.company.kext.fsd.sym...
warning: .o file "/path/to/object.o" more recent than executable timestamp in "/path/to/com.company.kext.fsd.sym
warning: Could not open OSO file /path/to/object.o to scan for pubtypes for objfile /path/to/com.company.kext.fsd.sym
:
done.
I was able to set a breakpoint in my kext and apparently hit it too as expected. However, I cannot single-step through the kext code - I get an error saying something like "no symbol information for this line was found; continuing to the end of the function". At the point where I hit the trap fault, I am unable print any arguments to the function, or locals.
I am sure what I intend to do is not an uncommon use of remote debugging. What am I doing wrong?
Thanks in advance for any help you can offer.
On Sat, Nov 21, 2009 at 4:35 PM, Brian Bechtel
<email@hidden> wrote:
On Fri, Nov 20, 2009 at 1:06 PM, mogambo <
email@hidden> wrote:
> Hi,
> I want to do remote debugging on 10.6.2 system. I found the following link
> about remote kernel debugging. I tried using the default kernel, rather than
> building my own and use mach_kernel in the debug kit.
Mount the disk image Apple provides, then issue the command
gdb -arch i386 /Volumes/KernelDebugKit/mach_kernel
inside gdb, issue the command
source /Volumes/KernelDebugKit/kgmacros
> However, when I issue
> attach <ip> command in the gdb, remote_connect keeps timing out. The
> boot-args on the target contains debug=0xd44.
It should be debug=0x144, rather than debug=0xd44. The additional bits
you've set are defined in technote 2118, "Kernel Core Dumps" at
http://developer.apple.com/mac/library/technotes/tn2004/tn2118.html
setting DB_KERN_DUMP_ON_PANIC means that you'll attempt to send a core
to the IP address in the boot-args argument _panicd_ip. Since you
probably haven't set that, you're probably confusing things.
The quick summary of 2 machine debugging is:
For ethernet connections, on the panicking machine:
% sudo nvram boot-args="debug=0x144"
reboot to let this new setting take affect.
Panic the machine, or NMI the machine by pressing the power key.
On the host machine, download the Kernel Debug Kit from
http://developer.apple.com/sdk, or use the search function on
developer.apple.com to find the appropriate Kernel Debug Kit which
matches the operating system version on the panicking machine.
Mount the Kernel Debug Kit image to create /Volumes/KernelDebugKit
% gdb -arch i386 /Volumes/KernelDebugKit/mach_kernel
(gdb) source /Volumes/KernelDebugKit/kgmacros
(gdb) kdp-reattach {ip address or name of panicking machine}
For firewire connections in Leopard or later, on the panicking machine:
% sudo nvram boot-args="debug=0x144 kdp_match_name=firewire"
reboot to let this new setting take affect.
Panic the machine, or NMI the machine by pressing the power key.
On the host machine, download the Kernel Debug Kit from
http://developer.apple.com/sdk, or use the search function on
developer.apple.com to find the appropriate Kernel Debug Kit which
matches the operating system version on the panicking machine.
Mount the Kernel Debug Kit image to create /Volumes/KernelDebugKit
In a terminal window, invoke fwkdp
% fwkdp
Leave that window open, and in another window, load gdb
% gdb -arch i386 /Volumes/KernelDebugKit/mach_kernel
(gdb) source /Volumes/KernelDebugKit/kgmacros
(gdb) kdp-reattach localhost
fwkdp redirects your gdb session so that gdb acts as if the host
machine was panicked. It isn't, of course, but the fwkdp session gives
you access to everything on the panicking machine.
Good luck
_______________________________________________
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