From owner-freebsd-current@freebsd.org Sat Oct 21 20:02:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46431E38B08 for ; Sat, 21 Oct 2017 20:02:50 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from smtp.imp.ch (smtp.imp.ch [IPv6:2001:4060:1:1001::13:196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09DCC6983F; Sat, 21 Oct 2017 20:02:50 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from [192.168.225.14] (dhclient-91-190-10-49.flashcable.ch [91.190.10.49]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by fgznet.ch (Postfix) with ESMTPSA id D0938C0B75; Sat, 21 Oct 2017 22:02:38 +0200 (CEST) Subject: Re: Segfault in _Unwind_* code called from pthread_exit To: Konstantin Belousov , Tijl Coosemans Cc: freebsd-current@FreeBSD.org, gerald@FreeBSD.org References: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> <20170824154235.GD1700@kib.kiev.ua> <20170824180830.199885b0@kalimero.tijl.coosemans.org> <20170825173851.09116ddc@kalimero.tijl.coosemans.org> <20170825234442.GO1700@kib.kiev.ua> <20170826202813.1240a1ef@kalimero.tijl.coosemans.org> <20170826184034.GR1700@kib.kiev.ua> From: Andreas Tobler Message-ID: Date: Sat, 21 Oct 2017 22:02:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170826184034.GR1700@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-CH Content-Transfer-Encoding: 7bit X-Scanned-By: Obelix Submit on 127.0.1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 20:02:50 -0000 On 26.08.17 20:40, Konstantin Belousov wrote: > On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote: >> On Sat, 26 Aug 2017 02:44:42 +0300 Konstantin Belousov wrote: >>> How does llvm unwinder detects that the return address is a garbage ? >> >> It just stops unwinding when it can't find frame information (stored in >> .eh_frame sections). GCC unwinder doesn't give up yet and checks if the >> return address points to the signal trampoline (which means the current >> frame is that of a signal handler). It has built-in knowledge of how to >> unwind to the signal trampoline frame. > So llvm just gives up on signal frames ? > >> A noreturn attribute isn't enough. You can still unwind such functions. >> They are allowed to throw exceptions for example. > Ok. > >> I did consider using >> a CFI directive (see patch below) and it works, but it's architecture >> specific and it's inserted after the function prologue so there's still >> a window of a few instructions where a stack unwinder will try to use >> the return address. >> >> Index: lib/libthr/thread/thr_create.c >> =================================================================== >> --- lib/libthr/thread/thr_create.c (revision 322802) >> +++ lib/libthr/thread/thr_create.c (working copy) >> @@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr) >> static void >> thread_start(struct pthread *curthread) >> { >> + __asm(".cfi_undefined %rip"); >> sigset_t set; >> >> if (curthread->attr.suspend == THR_CREATE_SUSPENDED) > > I like this approach much more than the previous patch. What can be > done is to provide asm trampoline which calls thread_start(). There you > can add the .cfi_undefined right at the entry. > > It is somewhat more work than just setting the return address on the > kernel-constructed pseudo stack frame, but I believe this is ultimately > correct way. You still can do it only on some arches, if you do not > have incentive to code asm for all of them. > > Also crt1 probably should get the same treatment, despite we already set > %rbp to zero AFAIR. Did some commit result out of this discussion or is this subject still under investigation? Curious because I got this gcc PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 Tia, Andreas