From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89710 invoked by alias); 8 Jul 2015 17:14:41 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 89266 invoked by uid 89); 8 Jul 2015 17:14:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-HELO: mx1.redhat.com Message-ID: <559D5A7A.8000905@redhat.com> Date: Wed, 08 Jul 2015 17:14:00 -0000 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Szabolcs Nagy , Torvald Riegel CC: Adhemerval Zanella , "libc-alpha@sourceware.org" , Marcus Shawcroft Subject: Re: [PATCH] pthread_once hangs when init routine throws an exception [BZ #18435] References: <556B7F10.40209@redhat.com> <557741C5.5060203@redhat.com> <559A8029.1000705@arm.com> <559A8DAE.9040604@gmail.com> <559A9789.3090805@linaro.org> <559AADC8.4030409@arm.com> <559AB627.2050006@arm.com> <559D02E2.5000303@arm.com> <559D4B4D.7090703@redhat.com> <1436373181.22407.38.camel@localhost.localdomain> <559D5539.5050606@arm.com> In-Reply-To: <559D5539.5050606@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00267.txt.bz2 On 07/08/2015 12:52 PM, Szabolcs Nagy wrote: > On 08/07/15 17:33, Torvald Riegel wrote: >> On Wed, 2015-07-08 at 12:09 -0400, Carlos O'Donell wrote: >>> On 07/08/2015 07:00 AM, Szabolcs Nagy wrote: >>>> (2) Should gcc support exceptions from async signal handlers? >>> >>> No. I don't think you can support it safely. >>> >>>> nptl/tst-join5 failure is more problematic: it fails because gcc >>>> does not seem to implement -fexceptions with the assumption that >>>> signal handlers can throw, in particular it assumes inline asm >>>> does not throw exceptions. If the syscall that is a cancellation >>>> point appears between pthread_cleanup_push and pthread_cleanup_pop >>>> in glibc internal code, the cleanup handler may not get run on >>>> cancellation depending on where gcc moved the syscall inline asm. >>>> (It is free to move it outside the code range that is marked for >>>> exception handling, this is what happens on aarch64 in pthread_join). >>>> This affects all archs, but some may get lucky. >>> >>> Ah! That's truly a terrible scenario. >>> >>>> (My understanding: gcc must be very strict about how it marks >>>> the code range for exception handling and assume any instruction >>>> may throw if it wants -fexceptions -fasynchronous-unwind-tables to >>>> work from signal handlers. Current compilers do not seem to support >>>> this so glibc internal code should not rely on it, which means the >>>> cancellation mechanism should not rely on exception handling at >>>> least not when the exception is thrown from the cancel signal >>>> handler. I think the gnu toolchain should not try to make pthread >>>> cancellation to interoperate with C++ exceptions nor to make >>>> exceptions work from signal handlers: no standard requires this >>>> behaviour and seems to cause problems). >>> >>> No, we just need to revert this patch and have C++ implement >>> std::call_once by itself. >> >> Would point (2) be taken care of by Adhemerval's cancellation changes? >> > > yes: if the cancel point syscall is not inline asm, > but extern call (that is not marked with nothrow) > then gcc -fexceptions should handle it correctly. > > asynchronous cancellation is still problematic, > but that is a special case. And we still have to support that case which makes this change a net loss of functionality. Therefore I think we need to revert this and try again 2.23. Cheers, Carlos.