From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21802 invoked by alias); 26 Jun 2018 11:46:09 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 15606 invoked by uid 89); 26 Jun 2018 11:45:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=H*f:sk:d1d58d8, H*i:sk:d1d58d8, interest X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 3 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Jun 2018 11:45:22 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 80785308FBA4; Tue, 26 Jun 2018 11:45:12 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-221.ams2.redhat.com [10.36.116.221]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0EB737DF7A; Tue, 26 Jun 2018 11:45:11 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id w5QBj9LB013534; Tue, 26 Jun 2018 13:45:10 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id w5QBj8cs013533; Tue, 26 Jun 2018 13:45:08 +0200 Date: Mon, 01 Jan 2018 00:00:00 -0000 From: Jakub Jelinek To: Florian Weimer Cc: Nathan Sidwell , GCC , GNU C Library , Binutils , gnu-gabi@sourceware.org Subject: Re: Invalid program counters and unwinding Message-ID: <20180626114508.GQ7166@tucnak> Reply-To: Jakub Jelinek References: <7ada5491-f3f4-e048-dfec-6e51cd937163@acm.org> <0c58f1bb-220c-d03d-7375-6066fb7d53e6@redhat.com> <0b0e49f0-7ed0-aa4e-a4df-d4286206dab5@acm.org> <8a147f05-509f-16a0-f108-9e76bcae4ea9@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Tue, 26 Jun 2018 11:45:12 +0000 (UTC) X-SW-Source: 2018-q2/txt/msg00023.txt.bz2 On Tue, Jun 26, 2018 at 01:39:18PM +0200, Florian Weimer wrote: > > The @code{noreturn} keyword does not affect the exceptional path > > when that applies: a @code{noreturn}-marked function may still > > return to the caller by throwing an exception or calling > > @code{longjmp}. > > > > IIRC, in gcc-land you have to give both noreturn and nothrow attributes > > to make it non-unwindable. > > Are you sure? I was under the impression that GCC did not do this because > it interferes too much with debugging. > > Furthermore, glibc marks abort as nothrow and noreturn, which is a bit > dubious, considering that it is perfectly fine to throw exception from > synchronously delivered signals. There is unwindable and unwindable. The default on many target is -fasynchronous-unwind-tables, where at every instruction .eh_frame contains everything needed to unwind. nothrow is only about .gcc_except_table if there is some unwind region etc. So you can still do _Unwind_Backtrace if you have noexcept functions. I don't see what is of interest on noreturn functions, either the calls them, then you have unwind info as usual, or it can tailcall them (that is what GCC usually doesn't do) and then it is like any other tail call, you can't see the original caller, but you can see a caller of that caller (or perhaps with a bunch of other frames missing), but still something unwindable. Jakub