Debugging the FreeBSD Kernel Transparently

An anonymous reader writes "To debug the FreeBSD kernel core dump efficiently, it is best to set up a remote debugging session between a development machine and the target machine, and remotely debug the kernel using serial communication. This article shows you how you can debug as many kernel images as you want; it becomes transparent to users once debugging starts, and your system's performance is not affected at all."

Comments

gdb remote is useful

[EmbeddedJanitor]

This is a very cool feature in gdb that is very commonly used to debug various embedded systems etc. Sometimes gdb remote uses a serial port or tcp from the host to a stub running in the target (as is the case with Redboot).

Also, gdb remote is often used to talk to a server that mimics a gdb remote stub and then turns the commands into some other connection into the target (eg. a JTAG debugger).

All up, this makes debugging embedded systems a lot simpler than it would otherwise be.

Re:Surely...

[MattPat]

Please, enlighten me as to how something can be "1, Redundant" if it's the first post?

Stop pissing about

[DrSkwid]

Get yourselves a system, with a proper debugger

Re: I was just about to post this story....

[Dolda2000]

I thought serial -> serial is merely a connection. Do I have to solder something?

You seem to think in strange ways. Indeed, serial -> serial is a connection, but surely, you realize that you have to make that connection with something, or did you think it was wireless?

Either way, to actually answer the question, you don't actually have to solder anything -- you should be able to buy a null modem cable anywhere. However, considering this is Slashdot, don't you think it would be easier to solder it yourself than going out to it? You wouldn't even have to leave your house. :)

What I don't understand is why they provide the listing for a 25 pin cable. Do any computers these days have anything but 9 pin RS-232 ports?

Wyse terminals work well for this.

[Anonymous Coward]

About 5 years ago I used an old Wyse terminal I got at a junkyard for exactly this job using a homemade cable, it worked beautifully. Once complete I then used the terminal to control and update the server from the living room couch.

I also used the same terminal and SoftIce to *ahem* "debug" several windows applications.

Wyse terminals (at least the older ones) are excellent gear, very sturdy, nice keyboards, though the monochrome monitor was a bit burnt in on the one I used. An industrial strength terminal for a rock solid OS. A match made in heaven. FreeBSD is an excellent OS.

It was a dark day for Linux

[Chatz]

It was a dark day for Linux when Linus said he didn't believe in kernel debuggers.

Last time I had a good look at what was on offer while developing a filesystem for multiple operating systems, I compared the tools for Linux to Windows, MacOSX, IRIX and Solaris.

Windows was clearly the best for remote kernel debugging with windbg and I don't see that changing anytime soon. A fully fledged debugger, automatic download of kernel symbols from Microsoft and your own repository, reliable capture of dumps etc. That and the API documentation made the black box nature of the O/S a much smaller issue than the open source community would like us to believe. I was always so much more confident if we had a crash due to our software at a customer site that with Windows we had the best chance of capturing and hopefully identifying the problem.

For live debugging IRIX was the best with icrash. Its port to Linux, lcrash, was not as good and reliable at the time, maybe its better now but the lack of symbol files it need on Linux always made it frustrating. And now IRIX is dead.

I've heard some really good things about dtrace, so Solaris and Mac look to have the best live debugging and tracing tool there is today...I see some progress on Linux ports which is great to see.

But when it comes to kernel debugging on Linux, the picture is still bleak.