On Wed, 9 Feb 2005, Harland Harrison wrote:
>
> Hi Garth,
>
> Thanks for helping! I really do need help with this.
>
> > It sounds like you have a panic log but you want to view memory
> > on the panicked machine. Is that right?
>
> No.
Good because the contents of memory is obviously not saved when all you
have is a panic log.
> I have a panic log for a crash which I cannot duplicate. The panic
> only happens on a Dual Processor G4.
> I have been trying to find out which line of our code causes the panic. That's all.
> Do I have to set up two-machine debugging for that?
No. All you need is the same version of your kext that whoever panicked
their machine is running.... (read on)
> The kexts are a driver, MacPortX, which depends on a shim, MacPortXEnetShim.
>
> Here are the commands I used, following TN2063:
>
> $su
> % gdb /mach_kernel
> (gdb)
> (gdb)
> add-symbol-file /Users/joeman/Desktop/PANIC/com.twowire.MacPortXEnetShim.sym
> (gdb)
> add-symbol-file /Users/joeman/Desktop/PANIC/com.twowire.MacPortX.sym
> (gdb) set print asm-demangle on
> (gdb) x/i 0x1558e900
> 0x1558e900 <com_twowire_MacPortX::probe(IOService *, long *)+148>: Cannot access memory at address 0x1558e900
> (gdb) x/i 0x1558eae0
> 0x1558eae0 <com_twowire_MacPortX::RegisterWithShim(void)+456>: Cannot access memory at address 0x1558eae0
Hmmm... that looks like it's telling you the line where it crashed
anyway... but cannot display the actual instruction for some reason.
> Those two addresses are right in the middle of the driver, which was loaded at the time.
> I tried both kextload and installing the driver (into "extensions") and re-booting.
> I generated the symbol files with kextload
> The kexts do run on the debugging machne.
> Their addresses show up in kextstat, and match the addresses I tried to read with x/i.
>
> If I "attach" gdb to another PID on this same machine, I can disassemble its memory.
> I have not been able to find a way to disassemble a kext, however.
>
> Do I have to set up two machines to follow the procedure in TN2063? Since it does NOT include
> a "target remote-kdp" command, I assumed that TN2063 used only one machine.
Ok well I'm sure I'm not following the technote, but here's what I do
when I get a panic:
1. Find the addresses in the panic.log that your driver _was_ loaded at.
If your driver was somewhere in the callstack then it should have printed
them out. These will look something like this:
Kernel loadable modules in backtrace (with dependencies):
org.defyne.driver.B2C2FlexCop(0.1)@0x1f998000
dependency: com.apple.iokit.IOPCIFamily(1.4)@0x395000
dependency: org.defyne.driver.MMInputFamily(0.5.3)@0x669000
2. Find the addresses in the panic.log backtrace and registers that you're
interested in, if you're lucky the PC will be at the address that crashed.
For example:
Backtrace:
0x000836E4 0x00083BC8 0x0001EDA4 0x00091634 0x00090920 0x0009406C
Proceeding back via exception chain:
Exception state (sv=0x1F8B7280)
PC=0x1F99D4E0; MSR=0x00149030; DAR=0x1FA82208; DSISR=0x42000000;
LR=0x1F99D3E0; R1=0x0CC0BAB0;
In that case I am interested in the PC and its caller the LR looks like
it's mine too. They both are values slightly higher than where the
B2C2FlexCop driver was loaded, so probably in its code - excellent.
3. Go and find your kext and open its Contents/Resources/executable with
gdb. e.g. for the case above:
cd /System/Library/Extensions/B2C2FlexCop.kext/Contents/MacOS
gdb B2C2FlexCop
4. Subtract the address where the kext was loaded from the address you're
interested in. Say I want to look at the code around the PC, which is at
address 0x1F99D4E0. So that's an offset of 0x1F99D4E0-0x1f998000 = 0x54E0
5. Now when you run gdb, it loads the code at address 0. But when it's
loaded in the kernel, it leaves the mach-o header (or something) in a page
before the code, so the code starts at 0x1000. This means you have to
subtract a further 0x1000 from your offset when you look at it in gdb. So
now my offset is 0x44E0.
6. display/disassemble/whatever the address.
disas 0x44E0 (disassemble the whole function)
disas 0x44E0-64 0x44E0+64 (disassemble around the crash)
info line *0x44E0 (show source line of the crash)
It will look nicer with 'set print asm-demangle on' too.
> thanks for your help
I hope that works for you!
> Harland Harrison
> 2wire.com
{P^/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden
This email sent to email@hidden
