Date: Tue, 14 Feb 2006 20:54:32 +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: <20060214205432.38121641.antoine.brodin@laposte.net> In-Reply-To: <20060214094744.A81690@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Marius Strobl <marius@alchemy.franken.de> wrote: > On Mon, Feb 13, 2006 at 09:37:19PM +0100, Antoine Brodin wrote: > > John Baldwin <jhb@freebsd.org> wrote: > > > On Monday 13 February 2006 13:36, Antoine Brodin wrote: > > > > John Baldwin <jhb@freebsd.org> wrote: > > > > > If there are kernel functions before the assembly ones (dependent on link > > > > > order) then this would wrongly bail when it hit those. I think you need > > > > > to do what the ddb stack tracing code does which is to lookup the symbol > > > > > name and do a bcmp() on the first 4 chars to recognize trapframes. > > > > > > > > I ran objdump -d on a sparc64 kernel and it looks like tl0_* and tl1_* > > > > are always at the beginning of the code, there is some kind of magic. > > > > > > magic aside, it would be best to use the same algorithm in both places IMO. > > > It would also be a lot more intuitive to other folks later on. > > > > There are 2 reasons why I didn't use db_search_symbol() and > > db_symbol_values() : > > > > - first they aren't reentrant, they use a global variable > > db_last_symtab and they can panic if a thread sets db_last_symtab to 0 > > while another one is using it. I found this in my mail archive : > > %%% > > Stopped at X_db_symbol_values+0x18: cmpl $0,0xc(%eax) > > db> trace > > Tracing pid 34983 tid 100093 td 0xc2e9c640 > > X_db_symbol_values(0,c0738214,e84859f4,e84859c4,7c) at X_db_symbol_values+0x18 > > db_symbol_values(c0738214,e84859f4,0,c89d19c8,0) at db_symbol_values+0x40 > > %%% > > It can be fixed easily but I don't have the fix anymore. > > You can use linker_ddb_search_symbol() and linker_ddb_symbol_values() > > too that are safer. > > > > - the second reason is performance. if you replace > > CTRSTACK(KTR_LOCK, &stack, 0, 1); > > by > > CTRSTACK(KTR_LOCK, &stack, 0, 0); > > in kern_lock.c, i.e. if you print the symbol name in the ktr traces, you > > will notice that your box is extremely slow. (you type ls, you wait 4 or 5 > > seconds and you have the result) > > > > Can't we just use what's done in support.S and add two dummy symbols > to mark the begin and end of the asm functions in question? There's already a tl0_base symbol. You can add a tl0_end (or tl1_end ?) symbol between tl1_intr and fork_trampoline. Cheers, Antoine
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060214205432.38121641.antoine.brodin>