From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26401 invoked by alias); 8 Jul 2015 16:52:18 -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 26388 invoked by uid 89); 8 Jul 2015 16:52:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-HELO: eu-smtp-delivery-143.mimecast.com Message-ID: <559D5539.5050606@arm.com> Date: Wed, 08 Jul 2015 16:52:00 -0000 From: Szabolcs Nagy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Torvald Riegel , Carlos O'Donell 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> In-Reply-To: <1436373181.22407.38.camel@localhost.localdomain> X-MC-Unique: xFNpnHMuT9SKj_7ZZASlew-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-07/txt/msg00264.txt.bz2 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. >=20 > Would point (2) be taken care of by Adhemerval's cancellation changes? >=20 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.