Date: Fri, 15 May 2015 12:08:09 -0400 From: John Baldwin <jhb@freebsd.org> To: sbruno@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: How to get anything useful out of kgdb? Message-ID: <19618854.y3EeXVtCGX@ralph.baldwin.cx> In-Reply-To: <55561803.9050102@ignoranthack.me> References: <554E41EE.2010202@ignoranthack.me> <2063489.pgabuk9nPJ@ralph.baldwin.cx> <55561803.9050102@ignoranthack.me>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, May 15, 2015 09:00:03 AM Sean Bruno wrote: > On 05/15/15 08:50, John Baldwin wrote: > > On Saturday, May 09, 2015 10:20:46 AM Sean Bruno wrote: > >> tl;dr What are the kernel config options to get good output of > >> kgdb? > >> > >> > >> I'm trying to get the ability to debug and display internal > >> variables, as one does, with kgdb. I'm *must* be doing this > >> wrong as I cannot get any useful output from accessing variables > >> that were JUST accessed in order to invoke a panic() that I have > >> inserted. This is a GENERIC kernel without INVARIANTS and > >> without WITNESS: > >> > >> https://people.freebsd.org/~sbruno/wtf_kgdb.txt > >> > >> I seem to have debug enabled and am able to browse source, but I > >> obviously haven't compiled correctly as things are optimized > >> out. > > > > 1) gdb7 does a better job. I hope to get the kgdb patches into > > the port soon. If you are feeling brave: > > > > # add texinfo for HEAD % pkg install gmake bison > > > > % git clone https://github.com/bsdjhb/gdb.git % cd gdb % git > > checkout freebsd-7.9.0-kgdb % fetch > > http://people.freebsd.org/~jhb/gdb/build % sh ./build % cd obj # > > or obj.i386 for i386 % gmake > > > > Then use /path/to/git/gdb/obj/gdb/kgdb > > > > 2) Even with gdb7 it can't figure out variables that it should > > figure out sometimes. Other options are either to find the > > variable in a higher frame (e.g. if it is something like 'td' or a > > driver softc) or to start poking around in the dissassembly to work > > out which register it is in (or which register points to a > > structure that contains it) and go from there. > > > > So one non-obvious thing that I'd like an explanation about: If I > manually break to the debbugger and cause a dump (doadump), how do I > poke around in the crash dump later on to find a thread that I'm > looking for, e.g. I want to poke at various bits inside em(4). The current thread in a crashdump is the one that calls dump or panic. If you want to find a different thread you have a couple of options. First, kgdb exposes each kernel thread as a thread to gdb. You can switch to individual kernel threads by using 'tid N' (where N is td_tid) or 'proc N' (where N is a pid). You can also use 'thread N', but that requires using gdb's internal thread number which has no relation to tids or pids. There are several ways to enumerate the list of threads in a core: 1) You can use 'info threads' in kgdb to get a list of threads. 2) You can run 'ps' against the crashdump using -N and -M to get the tid and pid values (at least until someone like glebius@ goes on more of an anti-libkvm tirade and removes crashdump support from ps). crashinfo runs ps by default, so if you have that enabled you can look in core.txt.N to get the list of tids / pids. 3) You can grab my gdb scripts at ~jhb/gdb/ and source 'gdb6'. That gives you a 'ps' command kind of like DDB's ps. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19618854.y3EeXVtCGX>