sparc64/93226: DEBUG_LOCKS (really stack_save()) causes panics on sparc64

[Antoine Brodin]

Marius Strobl <marius at alchemy.franken.de> wrote:
> On Mon, Feb 13, 2006 at 09:37:19PM +0100, Antoine Brodin wrote:
> > John Baldwin <jhb at freebsd.org> wrote:
> > > On Monday 13 February 2006 13:36, Antoine Brodin wrote:
> > > > John Baldwin <jhb at 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