Static linking and Thread Cancellation

Dubey, Abhishek abhishek.dubey at Vanderbilt.Edu
Wed Sep 5 15:02:08 UTC 2012


Thanks for the quick explanation.

> -----Original Message-----
> From: uclibc-bounces at uclibc.org [mailto:uclibc-bounces at uclibc.org] On
> Behalf Of Rich Felker
> Sent: Wednesday, September 05, 2012 1:13 AM
> To: uclibc at uclibc.org
> Subject: Re: Static linking and Thread Cancellation
> 
> On Tue, Sep 04, 2012 at 05:03:04PM -0500, Dubey, Abhishek wrote:
> > I am working with uclibc 0.9.33.2 and the latest buildroot with gcc
> > 4.7.1. I have a simple code that does thread cancellation. This code
> > succeeds when you use shared linking, but it fails into a segmentation
> > fault when you use static linking. Has anyone else faced this problem
> > before.
> 
> Sadly, I think this is a known issue with no easy fix. The NPTL implementation
> of cancellation uses C++-style exception handling with
> DWARF2 unwinding to implement cancellations, and in order to avoid a link-
> time dependency on the libgcc_s (or libgcc_eh in the static case) unwinding
> code, it insists on dlopening libgcc_s at runtime when cancellation is used.
> Not only does this break static linking; it also makes any program using
> cancellation non-robust since the code aborts the whole program if loading
> libgcc_s fails (e.g. due to running out of memory or exceeding some transient
> resource limit, or just about any random reason).
> 
> If it's possible, I think uClibc should take out the glibc/NPTL hack of loading
> libgcc_s at runtime, and instead introduce a link-time dependency of
> libpthread on libgcc_s. Or uClibc could just drop the exception-based
> implementation and replace it with a traditional linked-list-based one...
> 
> Rich
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc




More information about the uClibc mailing list