Date: Sat, 23 Nov 2002 15:59:12 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Doug Rabson <dfr@nlsystems.com> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 21417 for review Message-ID: <20021123235912.GA1296@athlon.pn.xcllnt.net> In-Reply-To: <200211232346.41171.dfr@nlsystems.com> References: <200211232017.gANKHAAk090869@repoman.freebsd.org> <200211232250.38412.dfr@nlsystems.com> <20021123230017.GB8744@dhcp01.pn.xcllnt.net> <200211232346.41171.dfr@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 23, 2002 at 11:46:41PM +0000, Doug Rabson wrote: > On Saturday 23 November 2002 11:00 pm, Marcel Moolenaar wrote: > > On Sat, Nov 23, 2002 at 10:50:38PM +0000, Doug Rabson wrote: > > > On Saturday 23 November 2002 8:17 pm, Marcel Moolenaar wrote: > > > > http://perforce.freebsd.org/chv.cgi?CH=21417 > > > > > > > > Change 21417 by marcel@marcel_nfs on 2002/11/23 12:17:09 > > > > > > > > Raw, untested implementation of EPC syscalls. > > > > > > This seems to be missing the bit after calling syscall() which > > > checks for a full exception_restore, e.g. after an execve and also > > > the check for calling ast(), e.g. after a signal. > > > > Yes. > > > > [snip] > > > > > One other thing after re-familiarising myself with exception.s. You > > > have added unwind records to all the kernel IVT entry points. This > > > is quite unhelpful when trying to debug kernel faults. The previous > > > version which manually unwound past the exception to the code which > > > faulted was extremely useful and saved me a lot of time in > > > debugging. Can we have it back please :-). > > > > If we want to use unwinding to get to the register state of the > > process, we can never unwind over the exception code. It's probably > > much easier to restart unwinding after it stopped at the exception > > entry point. This would also hold for signal handlers. Would a DDB > > command to resume unwinding work? > > I think it would be ok to just put back the code in db_stack_trace_cmd() > which spots kernel entry points and resets the unwind state based on > the contents of the appropriate stack frame. That would give complete > stack traces in DDB without disturbing the real unwind records. Ok. I may not get to it soon, so feel free to revert the change yourself if you want it badly enough :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021123235912.GA1296>