Slashdot Mirror

← Back to Stories (view on slashdot.org)

Debugging the FreeBSD Kernel Transparently

Posted by kdawson on from the deep-juju dept.

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."

12 of 55 comments (clear)

  1. Surely... by BluhDeBluh · · Score: 4, Funny

    If this news day gets any slower it's just going to just stop.

  2. I was just about to post this story.... by concernedadmin · · Score: 3, Informative

    Hehe, good to see others saw this as an influential story of the day.
    However, I have a question that perhaps others can answer.
    What does the diagram actually work out?
    Listing 1. 25-Pin NULL modem cabling

    2 3 Transmit Data
    3 2 Receive Data
    4 5 Request to Send
    5 4 Clear to Send
    6 20 Data Set Ready and Carrier Detect
    7 7 Signal Ground
    20 6 Data Terminal Ready

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

    Regards

    1. Re:I was just about to post this story.... by ampmouse · · Score: 4, Informative

      What does the diagram actually work out?
      This is a Null modem adapter. It allows you to connect to terminals, such as computers, together without a modem. It is the serial equivalent of a ethernet crossover cable.
    2. Re:I was just about to post this story.... by Spaceball_3000 · · Score: 2, Informative

      Normally from PC to modem the modem doesn't have wires crossed just a straight through cable, as the device automatically will swap certain pins like pins 2 and 3 in the device itself. But if your connecting from one computer to another using an straight through cable, the same pin like receive will connect to the same pin on the other PC (which is the receive), thus this will not work; as for normal operation you need to connect the Transmit to Receive from each PCs. Hope this helps.

    3. Re:I was just about to post this story.... by Alwin+Henseler · · Score: 2, Funny

      Do I have to solder something?

      You must be in the wrong place here. A true Slashdot user would ask: "Please, can I solder something to make this work?"

    4. Re: I was just about to post this story.... by Dolda2000 · · Score: 2, Interesting

      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?

  3. gdb remote is useful by EmbeddedJanitor · · Score: 2, Interesting
    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.

    --
    Engineering is the art of compromise.
  4. Stop pissing about by DrSkwid · · Score: 2, Interesting

    Get yourselves a system, with a proper debugger

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  5. debugging kernels by digitalderbs · · Score: 2, Funny

    This article shows you how you can debug as many kernel images as you want
    including zero.
  6. Unfortunately by edderly · · Score: 3, Funny

    Jayesh V. Rane works as a Systems Software Engineer for IBM and has five years of experience in product development, mostly working on network programming and storage management software. He has worked extensively on FreeBSD and AIX operating systems. Jayesh is currently working with the IBM India Systems and Technology Lab in Pune, India. You can contact him at jayesh.rane@in.ibm.com. Unfortunately Jayesh doesn't understand that compiling your kernel with -g will in fact affect the systems performance and is currently looking for a job where he can pretend to be a kernel engineer. Contact Jayesh at jayesh.rane@aol.com

  7. Wyse terminals work well for this. by Anonymous Coward · · Score: 3, Interesting

    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.

  8. It was a dark day for Linux by Chatz · · Score: 2, Interesting

    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.

    --
    There is folly and foolishness on the one side, and daring and calculation on the other. - Admiral Pellew, Hornblower