This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PowerPC] Fix eh unwind segfault
On Mon, Aug 30, 2004 at 11:30:52PM -0700, Richard Henderson wrote:
> On Tue, Aug 31, 2004 at 02:30:14PM +0930, Alan Modra wrote:
> > Another complication is that the unwind library functions need
> > to be thread safe, so we can't use static variables. That's why I use
> > a nested function for the signal handler.
>
> Signal handlers are by nature not thread safe. Without using
> clone directly, all threads share the same set of signal handlers.
> So as soon as you start unwinding in one thread, another thread
> may crash, because the nested function doesn't apply.
Ow! That makes it a bit difficult.
> So I don't see this patch as an improvement at all.
Yeah.. It would have been better to use static vars to pass the old
signal handler state to the unwind segv handler. That at least requires
a lock and usage count to control installation and deinstallation of the
handler. Or don't deinstall, and just lock around the installation.
> If you were really dedicated, you could re-implement mincore
> functionality by hand by scanning /proc/self/maps. Personally
> I'd prefer that you smack IBM kernel hackers around until they
> fix the syscall bug.
I did think about /proc/self/maps, and discarded the idea because it
seemed likely to add significant overhead to the unwinder, both in
initial scan and in checking some data structure holding the valid
ranges. Using (a fixed) mincore has similar problems. The bad thing
about both these solutions is that there's a race too: Someone might
unload a shared lib between the time we get the valid mem ranges and
when we access the memory.
BTW, thanks for considering the problem.
--
Alan Modra
IBM OzLabs - Linux Technology Centre