Re: Finding the syscall number in a crash dump for a given process?
On Wed, Mar 21, 2012 at 12:36:29AM -0700, Brian Buhrow wrote: hello. I'm in the midst of debugging some ufs_rename patches I'm trying to get working under NetBSD-5, and I'm now trying to assertain what the miscrient lwp's were doing before they caused the panic. ... I thought I could get the syscall from l-l_sysent, but no such luck. (gdb) print l-l_sysent $33 = (const struct sysent * volatile) 0x0 (gdb) You might manage to get the syscall number from the userspace call sequence. Is l_sysent the value that appears to have the syscall number saved in it on syscall entry? Might be zero because you are in a child returning from fork?? David -- David Laight: da...@l8s.co.uk
[GSoC idea] ASAN support in kernel and userland
Hi all, I wonder if the following idea matches the scope of the a GSoC project. For LLVM there exists a (platform specific) feature called ASAN, which provides a good chunk of the functionality of valgrind. As it is integrated into the compiler, it is quite fast. Since NetBSD is missing valgrind support and porting that is quite a lot work, ASAN provide quite an improvement. I think porting it to userland can be done in a month at most for a student, including dealing e.g. with libc overrides for assembler routines on x86. I also believe a basic working kernel implementation in the rest of the time is feasible. That would fit nicely between RUMP and normal kernel debugging as well. Thoughts? Joerg
Re: [GSoC idea] ASAN support in kernel and userland
On 21/03/2012 9:31, Joerg Sonnenberger wrote: I wonder if the following idea matches the scope of the a GSoC project. For LLVM there exists a (platform specific) feature called ASAN, which provides a good chunk of the functionality of valgrind. As it is integrated into the compiler, it is quite fast. Since NetBSD is missing valgrind support and porting that is quite a lot work, ASAN provide quite an improvement. I think porting it to userland can be done in a month at most for a student, including dealing e.g. with libc overrides for assembler routines on x86. I also believe a basic working kernel implementation in the rest of the time is feasible. That would fit nicely between RUMP and normal kernel debugging as well. Thoughts? I, for one, think this is a fantastic idea! I use valgrind extensively on Linux during the development of dhcpcd and it turns up some surprising issues that you don't see easily, nor experience when it is running. I have often wondered if there are any problems with the BSD specific code, but have no means of finding out. This project would allow this! Thanks Roy
Re: CVS commit: src/tests/modules
On Tue, Mar 20, 2012 at 05:50:11AM +, Jukka Ruohonen wrote: Module Name: src Committed By: jruoho Date: Tue Mar 20 05:50:11 UTC 2012 Modified Files: src/tests/modules: t_abi_uvm.sh t_modload.sh Log Message: Skip Xen. XXX: There should be a reliable way to detect MODULAR. This (untested) would add one (sysctl kern.module.modular would say 0 for non-modular kernels, or 1 otherwise). What do folks think? Martin Index: kern_module.c === RCS file: /cvsroot/src/sys/kern/kern_module.c,v retrieving revision 1.86 diff -u -r1.86 kern_module.c --- kern_module.c 4 Dec 2011 19:24:59 - 1.86 +++ kern_module.c 21 Mar 2012 12:23:46 - @@ -428,6 +428,17 @@ SYSCTL_DESCR(Enable verbose output), NULL, 0, module_verbose_on, 0, CTL_CREATE, CTL_EOL); + sysctl_createv(module_sysctllog, 0, node, NULL, + CTLFLAG_PERMANENT | CTLFLAG_IMMEDIATE | CTLFLAG_READONLY, + CTLTYPE_BOOL, modular, + SYSCTL_DESCR(The kernel is compiled to allow loading + of modules), NULL, +#ifdef MODULAR + true, +#else + false, +#endif + NULL, 0, CTL_CREATE, CTL_EOL); } /*
Re: CVS commit: src/tests/modules
On Wed, Mar 21, 2012 at 12:25:25PM +, Martin Husemann wrote: This (untested) would add one (sysctl kern.module.modular would say 0 for non-modular kernels, or 1 otherwise). I had to fix other parts of the kernel, but the patch now works as expected. Any objections? Martin
Re: CVS commit: src/tests/modules
On Wed, Mar 21, 2012 at 03:15:14PM +, Martin Husemann wrote: On Wed, Mar 21, 2012 at 12:25:25PM +, Martin Husemann wrote: This (untested) would add one (sysctl kern.module.modular would say 0 for non-modular kernels, or 1 otherwise). I had to fix other parts of the kernel, but the patch now works as expected. Any objections? Not from me :) module tests are also failing for e.g. sparc. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/tests/modules
looks good to me... On Wed, 21 Mar 2012, Martin Husemann wrote: On Wed, Mar 21, 2012 at 12:25:25PM +, Martin Husemann wrote: This (untested) would add one (sysctl kern.module.modular would say 0 for non-modular kernels, or 1 otherwise). I had to fix other parts of the kernel, but the patch now works as expected. Any objections? Martin !DSPAM:4f69f0a61987340033397! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
