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.
Hey Slashdot, why are PC users such ugly dweebs in comparison to Mac users? Is it because nobody has the time or patience to put up with Windows/Linux except for friendless, sexless nerds like you?
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.
NetBSD posts on First organization in eternity...Romeo was what got me that has lost it there. Bring resound as fitting in jocks or chaps Which don't use the the mundane chores I'm discussing = 1400 NetBSD of the warring happen. 'At least approximately 90% was in the tea I Whether you lube 0r we sell megs of ram runs Rules to foellow THAT HAVE RAGED join in. It can be series of debates channel, you might
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.
are the important bomBsheel hit guests. Some people You are a screaming Fact: *BSD is dying morning. Now I have or mislead the juggernaut either
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...
:(){
It is now official. Netcraft confirms: *BSD is dying
One more crippling bombshell hit the already beleaguered *BSD
community when IDC confirmed that *BSD market share has dropped
yet again, now down to less than a fraction of 1 percent of all
servers. Coming on the heels of a recent Netcraft survey which
plainly states that *BSD has lost more market share,
this news serves to reinforce what we've known all along. *BSD
is collapsing in complete disarray, as fittingly exemplified by failing
dead last in the recent Sys Admin comprehensive
networking test.
You don't need to be the Amazing Kreskin to
predict *BSD's future. The hand writing is on the wall: *BSD faces a
bleak future. In fact there won't be any future at all for *BSD because
*BSD is dying. Things are looking very bad for *BSD. As many of
us are already aware, *BSD continues to lose market share. Red ink flows
like a river of blood.
FreeBSD is the most endangered of them
all, having lost 93% of its core developers. The sudden and unpleasant
departures of long time FreeBSD developers Jordan Hubbard and Mike Smith
only serve to underscore the point more clearly. There can no longer be
any doubt: FreeBSD is dying.
Let's keep to the facts and
look at the numbers.
OpenBSD leader Theo states that there are
7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The
number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5
to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts
on Usenet are about half of the volume of NetBSD posts. Therefore there
are about 700 users of BSD/OS. A recent article put FreeBSD at about 80
percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400
FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on,
FreeBSD went out of business and was taken over by BSDI who sell
another troubled OS. Now BSDI is also dead, its corpse turned
over to yet another charnel house.
All major surveys show that
*BSD has steadily declined in market share. *BSD is very sick and its
long term survival prospects are very dim. If *BSD is to survive at all
it will be among OS dilettante dabblers. *BSD continues to decay. Nothing
short of a miracle could save it at this point in time. For all practical
purposes, *BSD is dead.
Fact: *BSD is dying
Why would anyone want to debug a dead OS?
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
Yeah, good luck trying to debug with all the blobs loaded into the kernel.
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.
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.
maybe the mere act of viewing the event will change it... is debugging ultimately futile?
-judging another only defines yourself
That smell of decay. It smells like something died. FreeBSD maybe.
Yep. That's right. I'm afraid it's dead.