Date: Thu, 16 Feb 2006 18:43:28 +0100 From: Antoine Brodin <antoine.brodin@laposte.net> To: Marius Strobl <marius@alchemy.franken.de> Cc: freebsd-sparc64@freebsd.org Subject: Re: sparc64/93226: DEBUG_LOCKS (really stack_save()) causes panics on sparc64 Message-ID: <20060216184328.749c4454.antoine.brodin@laposte.net> In-Reply-To: <20060216134823.S53619@newtrinity.zeist.de> References: <200602131150.k1DBo6S1074438@freefall.freebsd.org> <200602131223.51561.jhb@freebsd.org> <20060213193613.547d1b8f.antoine.brodin@laposte.net> <200602131430.11228.jhb@freebsd.org> <20060213213719.7767921e.antoine.brodin@laposte.net> <20060214094744.A81690@newtrinity.zeist.de> <20060214205432.38121641.antoine.brodin@laposte.net> <20060216134823.S53619@newtrinity.zeist.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Marius Strobl <marius@alchemy.franken.de> wrote: > Ok, how about the attached patch? It uses two pairs of dummy symbols > in exception.S to determine in stack_save() whether it was one of the > tl0_*() or tl1_*() asm functions; one pair for those in the .trap > section that is "magically" placed at the beginning of the .text > section via the linker script and the other pair for those in the > regular .text section. That way we don't rely on the location of > these functions in the kernel and don't have the performance penalty > of *search_symbol()/*symbol_values(). For consistency db_backtrace() > is changed to also use the new markers instead of bcmp()'ing with > the symbol names. If this fixes the panic, that's excellent Cheers, Antoine
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060216184328.749c4454.antoine.brodin>