From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 23:22:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8724116A4CE; Wed, 13 Apr 2005 23:22:10 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FEA443D39; Wed, 13 Apr 2005 23:22:07 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.0.0.20] ([151.196.164.10]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3DNPBaZ048017; Wed, 13 Apr 2005 17:25:11 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425DA8D3.3020505@samsco.org> Date: Wed, 13 Apr 2005 17:18:43 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org, current@freebsd.org References: <20050413061639.GK84649@wantadilla.lemis.com> In-Reply-To: <20050413061639.GK84649@wantadilla.lemis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.9 required=3.8 tests=PLING_QUERY autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Subject: Help Wanted! [Re: Does anybody use gdb for kernel debugging any more?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 23:22:10 -0000 [Resending to get wider coverage] All, While there are ways to work around some of the problems that Greg describes, the simple fact is that kernel debugging has gone downhill quite badly in the past year. Much of this decay appears to be due to the rush to get GDB 6.x imported in time for FreeBSD 5.3. I thank Marcel profusely for working on this, but more work is needed. I'm looking for volunteers to spend a few evenings digging into GDB, KDB, and DDB and working out as many issues as possible. Greg's email should serve as a good starting point for these tasks. Thanks, Scott Greg 'groggy' Lehey wrote: > In the last 10 months, I've had continual problems trying to use gdb > for kernel debugging. I'm currently revising my notes for the BSDCan > tutorial, and I can't work out how to get it to work any more. Since > about June of last year I've discovered: > > - I can no longer get a dump out of ddb with the 'panic' command. I > need to 'call doadump' > > - 'panic' doesn't only not do a dump, it doesn't reset the system > either. I need to press 'reset'. > > - The invocation to do kernel debugging with gdb keeps changing. A > year ago, it was simple: 'gdb -k kernel dump'. Now the -k command > is gone, and on what I believe to be a valid kernel dump, kgdb gives > me: > > # kgdb kernel.debug /var/crash/vmcore.1 > kgdb: cannot read PTD > > - It's possible that the dump isn't valid after all, of course. But I > can't debug the local system via /dev/mem either: > > # kgdb kernel.debug /dev/mem > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > > (kgdb) bt > #0 0x00000000 in ?? () > > - Firewire debugging no longer works if you haven't compiled firewire > into the kernel. Given the bugs I've seen above, I can't be > bothered to try building a kernel with firewire, since I don't have > much expectation that it will work either way. > > So what gives? Has the gdb interface withered away due to lack of > love? Do *you* use it? If so, how do you address the issues above? > > Greg > -- > See complete headers for address and phone numbers.