I'm developing a KEXT on mac using Xcode, After every compile I'm changing permissions through terminal and load the KEXT, then reading results from console app. Some of the mistakes in development giving system a kernel panic and I have to restart my mac, this is so annoying. I was wondering if there is a better way to develop and debug a KEXT?
This is too big a topic for an answer, but it is at least well documented, look at these documents from Apple:
When Things Go Wrong: Debugging the Kernel
Debugging a Kernel Extension with GDB
Technical Note TN2063: Understanding and Debugging Kernel Panics
Also note that you can get the output from kprintf() logging calls via Firewire (using the fwkpfv command-line utility on the other Mac) or Serial Port (mainly useful for testing in VMs, as modern Macs don't have serial ports). kprintf is synchronous, so unlike the kernel.log you will see the debug output even if it occurs immediately before a crash.
Related
I am trying to use Clion IDE to debug various NXP ARM M MCUs using J-link.
In case when program is only in RAM it works fine but but in case of flash targets after program load IDE often slows down for a while and then I will get timeout. Some click on pause button in right moment pauses program somewhere and allows me to debug...
My question is there any way how to see interactions of IDE with armgdb client or armgdb and j-link gdb server?
I tried to capture communication with gdb server using wire shark but it seems to be a binary protocol...
Thank you.
I found there is possibility to let gdb echo commands which showed me what is going on.
Unfortunately in case of Clion the only way is to put it into .gdbinit file in the root of project.
set trace-commands on
It showed me warning
warning: A handler for the OS ABI "Windows" is not built into this configuration
of GDB.
Which leads me to comment of this question gdb-multiarch (MINGW64) cannot determine architecture from executable?
Well I am not sure what caused Clion to hang but having .gdbinit with just set osabi none in it solved it.
I am new to windows driver development, so please bear with me if my question is being too stupid. Well, I am not sure why, as MSDN suggested and also the way I perceived, the host computer, e.g developing the driver, and the target computer, e.g debugging the driver, need to be two separate ones. why such separation? I did try to merge those two by deploying and debugging a driver on the host computer, in which I am developing a driver, and it seemed work with no objection from windows. Thanks.
PS. Source like this http://msdn.microsoft.com/en-us/library/windows/hardware/hh698272(v=vs.85).aspx got me think so.
Practically, when you are developing and testing a driver, in many situation you will get system crash (BSOD) and your system may not be bootable. In such situations your development + debugger environment is also gone/in-accessible.
Two separate machines are required for kernel debugging. You cannot debug self by obvious reasons (a debugger and a debuggee are in the same kernel and a deadlock appears). Of course, the target machine can be a virtual one.
When we develop a driver and test it the system will crash and a blue screen (called BSOD - blue screen of death)will show up. This is not the case like developing a User mode application and it crashed due to a memory error. Your driver will be running as a kernel mode application , If it crashes due to any illegal memory operation then the whole system is gone. It is not a simple issue to resolve , You need to log into safe mode and remove the driver from your system to recover it.
Due to this it is preferred to use a target machine mostly a VM on which the driver is installed and a host machine there we will be using a debugger to debug the driver.
Currently i'm developing a Cocos2d application for Mac OS X using xCode 4.2.1.So my problem is,sometimes while running the program the system get's stuck and show me a message like this- You need to restart your computer.Hold down the power button until it turns off.Then press the power button again. After receiving this message i can't proceed further without restarting the computer. What might be the problem behind this issue. Can anyone help me out.
What You get is called a kernel panic.
Resolution
Restart your Mac with a Safe Boot and see if the kernel panic happens
again
In most cases, kernel panics are not caused by an issue with your Mac.
They are most likely caused by an issue external to your Mac. If the
kernel panic doesn't happen again within a few weeks, you don't need
to troubleshoot further.
Depending on the model of Mac you have, restart one of these ways:
• Press and hold the Power button for several seconds to turn off your Mac. Then, press the Power button to startup your Mac.
• If you have a Restart button, press it.
As soon as your Mac starts up, hold down the Shift key to start up with a Safe Boot into Safe Mode. Note: If you are using a third-party
external keyboard and cannot start with a Safe Boot, try using an
Apple keyboard instead.
If your Mac has a kernel panic starting up, or while in Safe Mode, jump to the "Troubleshooting a recurring kernel panic" section of this
article.
If your Mac starts up without a kernel panic after a Safe Boot, restart your Mac by choosing Apple Menu > Restart…, then let it start
up normally. Run Software Update and install all available updates
until Software Update reports "Your software is up to date". Mac OS X
updates improve the tolerance for external issues such as malformed
network packets. For most kernel panics, this is all you have to do.
Note: It is possible, although very unlikely, that something on your network is sending your Mac malformed network packets which could cause recurring kernel panics. If the hardware and software on your Mac checks out as OK, check the devices on your network. Make sure your router's firmware is up-to-date, and that the router is not malfunctioning. Refer to your router's manufacturer for service and support.
And You also can try to find the problem in kernel.log. Go to the console app in the utilities folder and then type this:
tail -f /var/log/kernel.log
It will print kernel.log file to Your console.
More information:
Kernel Logs from the Command Line in Mac OS X.
How to log a kernel panic.
Kernel Panic.
I've to test some low level code on an ARM architecture. Typically experimentation is quite complicated on the real board, so I was thinking about QEMU.
What I'd like to get is some kind of debugging information like printfs or gdb. I know that this is simple with linux since it implements both the device driver for the QEMU Integrator and the gdb feature, but I'm not working with Linux. Also I suspect that extracting this kind of functionality from the Linux kernel source code would be complicated.
I'm searching from some simple operating system that already implements one of those features. Do you have some advice?
You don't need a target OS to debug code that's running inside QEMU -- QEMU already does that for you.
Specifically, QEMU supports remote debugging from GDB -- you can run QEMU with the appropriate command-line options and it will export an interface that a copy of GDB (running on the host machine) can connect to. At that point, you can debug the program in GDB pretty much just as if you were running it on the host machine.
http://wiki.osdev.org/GDB appears to have a bit more basic information; possibly not enough to completely get you started, but at least give you the basic idea and some terms to look for in the QEMU and GDB documentation. Skip over the bit about "Implementing GDB Stubs", which doesn't apply here since QEMU has one already, and start at the section on "Using Emulator Stubs". The short form is simply that you start QEMU with the -s option (export a GDB connection on localhost:1234) and the -S option (wait for a GDB "continue" command before starting execution), and then in GDB on your host you say target remote :1234 instead of run. Also, of course, you need to be using an ARM version of GDB rather than a native-x86 one.
(In addition, if you're willing to pay for a commercial solution, CodeSourcery's ARM toolchain has the IDE integration to set all of this up automatically, including support for "printf" to print into the debugger console. That works on a physical board, too, if you've got a hardware debugger. Usual disclaimer about me being a CodeSourcery employee applies -- but I do find it very easy to use.)
Update, 2012: CodeSourcery's toolchain is now called Mentor Graphics Sourcery CodeBench, but all the above still applies.
I realise that I am addressing your original problem here rather than your proposed solution (perhaps that's better?), but to use GDB (or Insight/GDB) directly on the target, use a low-cost JTAG tool and OpenOCD. An example of such a set-up and how to implement it can be found here.
If you have a larger budget, a more fully featured JTAG debugger may be useful, such as the Abatron BDI3000 with bdiGDB firmware which allows remote debugging and device programming over Ethernet with GDB and no special drivers or target debug agent.
Maybe a microkernel like OKL4 would suit your needs?
I'm currently setting up vmware Server 2.0 for kernel debugging with gdb ( see this setup guide ) and someone asked me why not use kvm?
So I ask: kvm vs. vmware for kernel debugging / USB driver development
what are the pros and cons of each?
Driver development? are you working on a driver for a particular piece of hardware? if so, then you probably won't be able to use virtualization, because the virtualized instance won't have access to the new hardware.
For this you will need two machines, one running a remote debugger on the other.
*Edit: * Apparently you're developing a driver for a USB Device? this is one area in particular that a VM actually Can help. These days most VM's have the ability to delegate specific USB devices to a guest OS.
That said, this situation doesn't really offer any benefits over the remote debugger option, because you still need a way to inspect the state of the running or crashed OS, and VM's offer very little assistance in this regard. You might be able to replay saved states from just before a crash.
You might be able to get a bit of traction using UML, which would allow you to do local debugging as on a regular user process, which is a little bit less trouble.
Instead of answering the direct question I'll add another option... Depending on if the kernel in question is a Linux kernel, and what part(s) of it you are working on, you might find that UserModeLinux (included in the 2.6.x source, and available as patch sets for 2.4 and 2.2) may trump both of those options.
As it runs the kernel as a userland process under the host kernel it is easier to attach common debugging tools to. I believe it is very commonly used in the early stages of updates/additions to file-system related code. If you are developing/debugging modules that interact directly with hardware it may be much less use to you though.
Reference links: home,
other
I recently started building GNU Mach/HURD and found the combination of QEmu/KVM to work really quite well.. for the following reasons:
QEmu presents quite a clean environment
Networking has alot of options
I can easily mount the filesystem using a raw device file / loopback
Bottom line is, for kernel work I just want the minimum of functionality to boot and see the result. VMWare is much more for usable virtualization rather than down-and-dirty.
There is however no comparison to booting on a real machine with real hardware. The VM environment can seem like a safety blanket somtimes ... because even my toaster would know what a Realtek RTL8139C was.
If it is a "real hardware" device, of course, vmware will not emulate it, so you won't be able to debug the driver under it (nor will any other virtualisation software, unless you extend one to do so).
Device driver debugging can be done to some extent with a real hardware machine with a normal kernel - although there are obviously things you can't do - like set breakpoints.
It is still possible to attach a debugger to the kernel and inspect stuff. Moreover, traditional printf() debugging is quite possible (printk, anyone), and there are various features in the kernel which make debugging easier. It's possible to build the kernel with various debug options to try to detect pointer problems, memory leaks etc.
By default, the kernel even gives a nice-ish stack trace on the log when it encounters an OOPS or BUG condition (obviously this does not necessarily get written anywhere if the system hangs or crashes). Of course a pointer-out-of-range condition happening inside an interrupt is a recipe for disaster, but you could still get a stack trace on the screen immediately before the panic :)