libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libunwind-devel] Re: [patch] Fix for race in dwarf_find_save_locs


From: Arun Sharma
Subject: [Libunwind-devel] Re: [patch] Fix for race in dwarf_find_save_locs
Date: Tue, 24 Nov 2009 15:06:46 -0800

On Tue, Nov 24, 2009 at 1:31 PM, Paul Pluzhnikov <address@hidden> wrote:
On Tue, Nov 24, 2009 at 12:12 PM, Arun Sharma <address@hidden> wrote:

> You're right. This part is broken for dwarf. We'll need to fix it along the
> lines of src/ia64/Gscript.c

Tricky (unless we drastically reduce cache size): current
sizeof(local_addr_space) on x86_64 is 43664, and adding this much
TLS to each thread may run into glibc issue: glibc does not

Large per-thread cache size doesn't seem to be a dwarf or x86_64 specific issue. Seems to be there on ia64 (from where this code was derived) as well.
 
automatically add required TLS space at pthread_create, so if you
specify e.g. 64K stack, pthread_create will fail with EINVAL just
because you linked to libunwind.

> Agree that fix#1 is suboptimal. The choice is really between fix #2 and a
> fixed UNW_CACHE_PER_THREAD.

Hmm, I don't think that's the choice: libunwind *should* work with either!

If you meant any caching policy, yes it should. But dwarf is broken right now for UNW_CACHE_PER_THREAD and it remains broken with fix2A. I'll apply fix2 instead.

If we find a reasonable implementation strategy (eg: smaller caches) for per thread caches in the future, we can try to create a more optimal code path (which doesn't involve memcpy) for that case.
 
 -Arun


reply via email to

[Prev in Thread] Current Thread [Next in Thread]