Date: Wed, 3 Apr 2002 09:18:06 +0930 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jake Burkholder <jake@FreeBSD.org> Subject: Re: cvs commit: src/sys/conf options src/sys/kern kern_ktr.c src Message-ID: <20020403091806.N26122@wantadilla.lemis.com> In-Reply-To: <XFMail.20020402110917.jhb@FreeBSD.org> References: <20020402122111.A20507@wantadilla.lemis.com> <XFMail.20020402110917.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 2 April 2002 at 11:09:17 -0500, John Baldwin wrote: > > On 02-Apr-2002 Greg 'groggy' Lehey wrote: >> On Sunday, 31 March 2002 at 21:35:26 -0800, Jake Burkholder wrote: >>> jake 2002/03/31 21:35:26 PST >>> >>> Modified files: >>> sys/conf options >>> sys/kern kern_ktr.c >>> sys/sys ktr.h >>> sys/sparc64/sparc64 genassym.c >>> Log: >>> ktr changes to improve performance and make writing a userland utility to >>> dump the trace buffer feasible. >>> - Remove KTR_EXTEND. This changes the format of the trace entries when >>> activated, making writing a userland tool which is not tied to a >>> specific >>> kernel configuration difficult. >>> >>> These changes will break gdb macros to decode the extended version >>> of the trace buffer which are floating around. Users of these >>> macros should either use the show ktr command in ddb, or use the >>> userland utility which can be run on a core dump. >> >> I really think this is wrong. It removes a very useful debugging >> tool. IIRC it was possible to disable KTR_EXTEND when necessary. >> Even if not, it was still an option, and I think it should remain one. >> There are plenty of places where you won't be able to use the userland >> tool. > > In which case you can use 'show ktr' in DDB or a simple macro in > gdb. This doesn't preclude using a macro in gdb, it just makes the > macro a bit more complicated. If you can come up with a macro, I'll retire my objections. The problem I recall is that it has to do a sprintf with one of the arguments as format. I wasn't able to find a way. I still think this is a Bad Idea. It would be trivial for the system call for tdump to return EINVAL if KTR_EXTEND is set. There's little enough debug assistance as it is; there's certainly no reason to remove any of it which is useful. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020403091806.N26122>