From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Carlos O'Donell Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf Date: Wed, 28 Feb 2018 15:23:43 -0800 Message-ID: <3764b0a1-9f26-6f5f-1bc5-d374f2672f3a@redhat.com> References: <20180201205757.51911-1-hjl.tools@gmail.com> <90d3ee18-c292-117f-a0c1-7822e340ca02@redhat.com> <87a7vyjsqv.fsf@mid.deneb.enyo.de> <87vaelbetu.fsf@mid.deneb.enyo.de> <87fu5pb7ql.fsf@mid.deneb.enyo.de> <877er1b4zp.fsf@mid.deneb.enyo.de> <87371pb3ga.fsf@mid.deneb.enyo.de> <87tvu59o21.fsf@mid.deneb.enyo.de> <87po4t9mxt.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1519860117 13382 195.159.176.226 (28 Feb 2018 23:21:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Feb 2018 23:21:57 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: GNU C Library To: "H.J. Lu" , Florian Weimer Original-X-From: libc-alpha-return-90692-glibc-alpha=m.gmane.org@sourceware.org Thu Mar 01 00:21:53 2018 Return-path: Envelope-to: glibc-alpha@blaine.gmane.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:subject:to:cc:references:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=GYiBDrwYswrNT2n3 n7KhJLlqLX/EZXUSLNW85rYzHj4UZYv0PI60x94Duvq+JNJqXKmtr2DkSggw6hsJ 5lH2ZjpHZ8HaHGYEP/Fe9LEPwwFXsxMjKfvW/uAnTTToPxvJDBT+cAseyKXjE2EN EdB+zHntfePoIVqzEQixiCRzwec= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:subject:to:cc:references:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=cWxG6ZOcsZl7Zl2R+MMfl5 srn4M=; b=lmt1YEqoSTNu86mmQ1rBcrO5y1jr71FKKFsgquVOk4g0p8uto6xjwt NJZHkvZ+qQjirCEzqEbUSjnpAa2ywcubZOYAE/N03ZmHEUMmOIKdJV0yAxV5xMAX TFLd1mTHFVe77aP3Cp7Ws2MWM2Fb5N41kMh5WMPtdIhU+y92Bj6Rk= Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mail-qt0-f195.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=p4/3cnkORJiXJr+9mCeN8pj/ixp8rUjtk22f6T0yCWU=; b=rRuQfpNuQIcr9pn6rzH6v//bfrxObw7oQZqxHcCQmlZMGRxMZH3QI8AV90Gz7wVRTO Xej9NlUBAbZXVnkb5+kk5n+lCfXCx7kVXVMvtYcrx2ffjknpocjC8dZd17x1NKO8u6Xc RQ3Asme/Kkg9AJ92PIc62E9A8ROu0D2TqZf17PlONW7hjSuBL4rNZe9++hSFi84yUQB+ ZIFizRB7WD4NbFwnX7SYznvWM7fRpoIGM9kbpf5wlr0mlwySSZTotv+2iSWJoJTITjmI oclIAb+05FakzY9LKP+YrSEerCxxUb7+Oo+JVZhWmHBOcLEKILI4YI/zMLMksrkmPObo xDgw== X-Gm-Message-State: APf1xPA5OpEGLpvezeLuccEKI0wvqlT6C8x/RMnWi+Zaartipa8ufgmS l2IWvmJ6zcPK2UVzpbd3qJ7c0vyhk4E= X-Google-Smtp-Source: AG47ELvHxTDbtCQXJmt2BONBaG+kzxy0Wedld/jEFN8iOx73i9EllHJHtDBSJhawQ+gIAvM/tYVlPw== X-Received: by 10.237.39.38 with SMTP id n35mr33024297qtd.327.1519860226803; Wed, 28 Feb 2018 15:23:46 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:83023 Archived-At: Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erB2n-0002mz-6o for glibc-alpha@blaine.gmane.org; Thu, 01 Mar 2018 00:21:53 +0100 Received: (qmail 122856 invoked by alias); 28 Feb 2018 23:23:51 -0000 Received: (qmail 122745 invoked by uid 89); 28 Feb 2018 23:23:51 -0000 On 02/25/2018 07:55 PM, H.J. Lu wrote: > On Sun, Feb 25, 2018 at 6:13 AM, Florian Weimer wrote: >> * H. J. Lu: >> >>> On Sun, Feb 25, 2018 at 5:49 AM, Florian Weimer wrote: >>>> * H. J. Lu: >>>> >>>>> On Sun, Feb 25, 2018 at 5:31 AM, Florian Weimer wrote: >>>>>> * H. J. Lu: >>>>>> >>>>>>> libpthread cancellation implementation passes cancel_jmp_buf to >>>>>>> libgcc unwinder, >>>>>> >>>>>> Oh. Where does it do that? If you mean _Unwind_ForcedUnwind, I think >>>>>> that's just an opaque closure argument for the callback. >>>>> >>>>> Yes. Libgcc unwinder needs to deal with it. >>>> >>>> Please point me to the code. Thanks. >>> >>> sysdeps/nptl/unwind-forcedunwind.c has >>> >>> _Unwind_Reason_Code >>> _Unwind_ForcedUnwind (struct _Unwind_Exception *exc, _Unwind_Stop_Fn stop, >>> void *stop_argument) >>> { >>> if (__glibc_unlikely (libgcc_s_handle == NULL)) >>> pthread_cancel_init (); >>> else >>> atomic_read_barrier (); >>> >>> _Unwind_Reason_Code (*forcedunwind) >>> (struct _Unwind_Exception *, _Unwind_Stop_Fn, void *) >>> = libgcc_s_forcedunwind; >>> PTR_DEMANGLE (forcedunwind); >>> return forcedunwind (exc, stop, stop_argument); >>> } >> >> Thanks. I think stop_argument ends up in the private_2 member inside >> unwind.inc, which is only passed back to the callback (the stop >> function pointer) in _Unwind_ForcedUnwind_Phase2, and not interpreted >> by libgcc itself. So this shouldn't be a problem. > > Please take a look at hjl/setjmp/cancel branch: > > https://github.com/hjl-tools/glibc/tree/hjl/setjmp/cancel OK. > Functions, like LIBC_START_MAIN, START_THREAD_DEFN as well as these > with thread cancellation, call setjmp, but never return to their > callers after longjmp returns. This patch adds > and to provide a version of setjmp family functions, > __setjmp_cancel and __sigsetjmp_cancel, which are used to implement > thread cancellation. The default __setjmp_cancel and __sigsetjmp_cancel > are defined as setjmp and __sigsetjmp, respectively, which are the same > as before. > On x86, a different version is added to avoid saving and restoring > shadow stack register. __libc_longjmp, which is a private interface > for cancellation implementation in libpthread, is changed to call > __longjmp_cancel instead of __longjmp. The consequence of this solution is that any function calls after the first longjmp will continue to extend the shadow stack because there is no restoration? I think this is OK, you effectively need to have enough shadow stack to run through all of the unwind functions as if they were nested frames on the shadow stack. Do we see that being a problem? > This leaves cancel_jmp_buf unchanged. But is it worth it? Absolutely it is worth it. This new design looks much simpler to support. The technical trade is as follows: * Three new versioned symbols for __sigsetjmp, __sigsetjmp_cancel, and __setjmp_cancel. * You can avoid versioning by placing the shadow stack pointer such that it is written into the pad[4] of the cancel_jmp_buf, and thus it would always have space to be written. However, it is cleaner to have cancel versions of these functions that do less. vs. * An ABI change that requires coordination across glibc, gcc, and binutils to ensure there is a "flag day" where the ABI can be correctly selected at runtime. The latter is not easy to execute for downstream, and the versioned symbols provide a good barrier in terms of compatibility and errors reported by the dynamic loader. > 1. I have to add __setjmp_cancel and __sigsetjmp_cancel which won't > save and restore shadow stack register. OK. > 2. I still need yet to add the new version of __sigsetjmp for older binaries. OK. > 3, Older .o files compiled against glibc 2.27 are still incompatible with > glibc 2.28. This is normal, and has never been assured. -- Cheers, Carlos.