This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #16159] Do not backtrace recursively.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Thorsten Glaser <tg at debian dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 19 Nov 2013 22:35:12 +0100
- Subject: Re: [PATCH][BZ #16159] Do not backtrace recursively.
- Authentication-results: sourceware.org; auth=none
- References: <20131114190329 dot GB26168 at domone dot podge> <loom dot 20131118T120309-727 at post dot gmane dot org>
On Mon, Nov 18, 2013 at 11:03:53AM +0000, Thorsten Glaser wrote:
> OndÅej BÃlka <neleai <at> seznam.cz> writes:
>
> > --- a/ports/sysdeps/m68k/backtrace.c
> > +++ b/ports/sysdeps/m68k/backtrace.c
>
> > + static __thread int recursed = 0;
>
> m68k has a huge penalty for TLS (at least one syscall).
>
Ok, so we need more involved code. A tls access is only needed not to
run __libc_once twice initialization routine contains dlopen/lock which is
even slower. For that we need to define reentrant version of
libc_once and handle its failures.
A second question would be why you have slow TLS? As m68k are mostly
single core you could add a alternative TLS access without syscall
overhead.
You need to add in kernel a syscall where you specify a static TCB address
and kernel will save/restore it on context switches.
To support possible future multithread processors you could for example
check if a TCB pointer is null and proceed with syscall.