Slashdot Mirror
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."
If this news day gets any slower it's just going to just stop.
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
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.
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
Test, please ignore.
We just bought a few brand new PCs recently, and they didn't come with RS-232 ports at all.
Laptops almost never have serial or parallel connectors.
But, you are correct, 25-pin serial is rather rare...
:(){
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
Go away to another land and find your fortune cookie u kinky kernel.
Yeah, good luck trying to debug with all the blobs loaded into the kernel.
Well, that isn't hard to figure out. I guess it is true that beautiful people are really fucking dumb.
For every Mac user there are about 10,000 PC users. Of that 10,000 about 75 are beautiful, so beautiful PC users outnumber you trendoid Mac dorks by a far margin.
Do you understand, honey ?
The End of FreeBSD
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - k
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.
Why was this modded as troll? Netcraft has confirmed - BSD is dying!
Something tells me that if the kernel has dumped core and dropped down into a debugger, the users are going to notice something. Just a hunch.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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
Why it can't be like ddb, the OpenBSD debugger. You press Ctrl+Alt+Esc and Bam! you are debugging the kernel, with full symbols and breakpoints. Very cool kernel debugger.
The "system performance" he is referring to is on your development machine, i.e. where you are running kgdb. Of course compiling your kernel with -g will affect performance on the target machine! By not running a development kernel on your development machine you are not affecting your system's performance. I don't know about you but it really affects my system's performance when the kernel panics.
As far as I know, it shouldn't make a difference. The only thing -g does, is adding debugging information (DWARF?) to the kernel's binary, stored in a seperate section. If you'd load that kernel, it would cost a lot more memory, but wouldn't slow down your system. The FreeBSD people aren't stupid, so what they do: they strip the debugging info before they install it. You load the kernel without the debugging information, but use the other one with kgdb.
You forgot the part about how it's more like there are about 5 mac users for every 100 pc users which would mean the ratio is 1 to 20, which means 500 to 10000. If we now assume that your comment about 75 of every 10000 pc users being beautiful then that means the ratio of mac users to beautiful pc users is 500 to 75 or 100 to 15. You lose.
maybe the mere act of viewing the event will change it... is debugging ultimately futile?
-judging another only defines yourself