kgdb on sparc64

Marius Strobl marius at
Sun Nov 9 10:32:36 PST 2008

On Wed, Nov 05, 2008 at 08:56:30PM +0100, Ruben de Groot wrote:
> On Mon, Nov 03, 2008 at 11:11:11PM +0100, Marius Strobl typed:
> > > After upgrading to 7.1-PRERELEASE last month I'm seeing some 
> > > spontaneous reboots with crash dumps on this Netra X1. How
> > > can I debug this as kgdb seems not to be working?
> [...]
> > I've never had much luck with kgdb(1) on any arch and use
> > devel/gdb53 which still has '-k' instead (for sparc64 just
> > remove the BROKEN from the port Makefile; the problem
> > leading to that one being added was fixed some time a go).
> The installation of gbd53 fails unfortunately with:
> gmake[1]: Leaving directory `/usr/ports/devel/gdb53/work/gdb-5.3/sparc64-portbld-freebsd7.1/libiberty'
> gmake[1]: Entering directory `/usr/ports/devel/gdb53/work/gdb-5.3/libiberty'
> rm -f libiberty.a pic/libiberty.a
> sparc64-unknown-freebsd7.1-ar rc libiberty.a \
>           regex.o cplus-dem.o cp-demangle.o md5.o alloca.o argv.o choose-temp.o concat.o dyn-string.o fdmatch.o fibheap.o floatformat.o fnmatch.o getopt.o getopt1.o getpwd.o getruntime.o hashtab.o hex.o lbasename.o make-temp-file.o objalloc.o obstack.o partition.o pexecute.o safe-ctype.o sort.o spaces.o splay-tree.o strerror.o strsignal.o ternary.o xatexit.o xexit.o xmalloc.o xmemdup.o xstrdup.o xstrerror.o  
> gmake[1]: sparc64-unknown-freebsd7.1-ar: Command not found
> gmake[1]: *** [libiberty.a] Error 127
> gmake[1]: Leaving directory `/usr/ports/devel/gdb53/work/gdb-5.3/libiberty'
> gmake: *** [all-libiberty] Error 2
> *** Error code 2
> Stop in /usr/ports/devel/gdb53.

Oh, apparently it has developed a new problem since the
gcc34 problem was fixed in February, sorry...

> > For your purposes it's probably simpler to just build a
> > kernel with debugger by adding "options DDB", "options KDB"
> > and "makeoptions DEBUG=-g". Then when the kernel panics
> > just enter "backtrace" on the console. With a X1 you
> > most likely use serial console anyway so you can easily
> > capture the output.
> I'll build a kernel with those options just in case. But
> would rather not use it on this particular machine, as it is 
> a production server and should not be down for extended periods
> of time.

If you additionally either also add "options KDB_TRACE" and
"options KDB_UNATTENDED" or set "debug.trace_on_panic=1"
and "debug.debugger_on_panic=0" via sysctl(8) with a
debugger-enabled kernel, the debugger will automatically
print a backtrace to the console and then reboot the
machine and thus minimizing downtime. Printing the
backtrace might require the latest 7-STABLE though.

> Meanwhile, moving over websites to another machine (another X1,
> but running -current) that seems to be more stable ATM.

That's what puzzles me as every sparc64-specific change
in 7-STABLE since 7.0-RELEASE also is in -current except
for one stricter check in -current. So I guess you're
hitting one of the MI stability issues people are
reporting for 7.1-PRERELEASE.


More information about the freebsd-sparc64 mailing list