Date: Mon, 14 Sep 1998 21:45:58 +0800 From: Peter Wemm <peter@netplex.com.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Andrzej Bialecki <abial@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/i386 machdep.c Message-ID: <199809141346.VAA10681@spinner.netplex.com.au> In-Reply-To: Your message of "Mon, 14 Sep 1998 14:28:41 %2B0200." <24254.905776121@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
> In message <199809141225.UAA10464@spinner.netplex.com.au>, Peter Wemm writes:
> >Poul-Henning Kamp wrote:
> >> In message <199809141147.EAA18800@freefall.freebsd.org>, Andrzej Bialecki
wri
> > te
> >> s:
> >> >abial 1998/09/14 04:47:41 PDT
> >> >
> >> > Modified files:
> >> > sys/i386/i386 machdep.c
> >> > Log:
> >> > This implements retrieving the contents of message buffer via sysctl(3)
> >> > as "machdep.msgbuf". It's needed in case of using stripped kernels, whe
re
> >> > normal dmesg (which has to use kvm) doesn't work.
> >> >
> >> > The buffer is unwound, meaning that the data will be linear, possibly
> >> > with some leading NULLs.
> >>
> >> Now dmesg should be changed to use this interface, so that one less
> >> program needs access to /dev/kmem...
> >
> >I've found dmesg's ability to extract the msgbuf from a crashdump to be
> >invalueable.. ie: "dmesg -N kernel.41 -M vmcore.41". It would be a shame
> >to loose this ability without some other replacement. The same goes for
> >ps(1).
>
> I think we should have a crash(8) style tool for this, or maybe a set
> if gdb macros.
>
> /dev/kmem should die
By all means, yes, it'd be great when/if it goes away, but I doubt that
gdb macros will ever even remotely fill the hole left.
The main reason why it won't fly is that you need a -g kernel, and people
generally don't compile -g kernels unless things are getting pretty grim.
gdb is overkill for what is badly needed.
crash(8) would be great, if only it could ever get written. :-)
What I'd suggest is that the most sensible thing would be to have a
general supporting framework that could allow modules to be linked in to
extend the command set. At a minimum, it'll need a pretty complete ps,
netstat, dmesg, stack traceback, process state dumps, a data examination
tool, disassembler, and the ability to teach it about new structures.
Macros and scripting would be really nice. Savecore could then also do a
post-crash automatic analysis right next to kernel.x and vmcore.x.
Most of what sysv crash(8) does is display various tables and structures.
Some way of processing include files and/or stabs output would be really
nice to shortcut the legwork.
Then, by all means, fry use of libkvm and eventually itself. I'll be there
to help kill it. :-)
Cheers,
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809141346.VAA10681>