Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Feb 2006 18:09:36 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        Marius Strobl <marius@alchemy.franken.de>
Cc:        freebsd-sparc64@freebsd.org, Antoine Brodin <antoine.brodin@laposte.net>
Subject:   Re: sparc64/93226: DEBUG_LOCKS (really stack_save()) causes panics on sparc64
Message-ID:  <200602161809.38389.jhb@freebsd.org>
In-Reply-To: <20060216134823.S53619@newtrinity.zeist.de>
References:  <200602131150.k1DBo6S1074438@freefall.freebsd.org> <20060214205432.38121641.antoine.brodin@laposte.net> <20060216134823.S53619@newtrinity.zeist.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 16 February 2006 07:48, Marius Strobl wrote:
> On Tue, Feb 14, 2006 at 08:54:32PM +0100, Antoine Brodin wrote:
> > 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.
>
> 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.

Looks like a winner, thanks!

-- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200602161809.38389.jhb>