From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22684 invoked by alias); 26 Jun 2018 11:46:10 -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 21088 invoked by uid 89); 26 Jun 2018 11:46:08 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:d1d58d8, H*i:sk:d1d58d8 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham 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: mail-yw0-f173.google.com Received: from mail-yw0-f173.google.com (HELO mail-yw0-f173.google.com) (209.85.161.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Jun 2018 11:46:06 +0000 Received: by mail-yw0-f173.google.com with SMTP id i143-v6so4479265ywc.9; Tue, 26 Jun 2018 04:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zTiLQi0UgiH08De59IlymUTrt4PQxkdMOpUJMmRIehs=; b=MssyuJUh7OPkpzDheGdgOOHJB0t6hQRK6xTHq/QIvW0JIP1a1Rw0XH1aQ8yU6N6S9+ wWTAsfl3B5ZHNOfOc6nAnYrGUMmVM5pjnNAC79IaJX8h0ewhYXm6VWTKHcfh2K6m4hca 5zyiu84alWI9BYGPF5Km2NxhHTw5OdTSxSgkKr4XqCvmZ9QG+7ve6T/pujtJzAgmt7lZ OUrrs1J2aj/tJJAPvX9F7YBrYEMZFxrIGurJbsHeCX9nKN8kRaZc6r0t2q1M+iY53O5Y o1Bpvy7KKPSdDk6AUaD1nwyiEhfl7NpV9g2WHhn+/EwfLhR+yYehD57iR+7X0RHMZaKw 4LEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zTiLQi0UgiH08De59IlymUTrt4PQxkdMOpUJMmRIehs=; b=LwX4nw5+zKCD/h3CmV2hduGRd6sTvFaFshk6bal65S/lDnvSRqdyK39k7s80SQh8eR diH1uHQi3NGP6C3/FGF7gPluxpQBiGg6qcQbgiaMmaPxnlHYXfexq0Szz7HOwzCegx6u wm6SjPmaOqftaz4MLZlYDpGqjYZJH6K1/JIbbV7x3ubhwi0pD3bSSe0wB063gciF4lRL GIW8s+XtUVWD5HrDSbR7xafTlqS7cKaYHlzgNlYPfka95tr9jhX8RbpUGrln2ZtpsMK1 yRJoWbc/a5ZddEpegQg52g34aqdOKH9NsZsNzPhO0Pou9OJOZRlPfBrfWV4k7+2LgszF pa+w== X-Gm-Message-State: APt69E17K5MFlHNJLB7iijHBIITw3vRsKhM9QEGppXVr2RlBciGnjW1j /GVUsIqEpSNlNd1o35SSIc62zQ== X-Google-Smtp-Source: AAOMgpcGeABC5e7+Z71xxyPLINbQFius64nYmZB/VPUXy55LObeHcqUNogvEAkArISGCmoNuD2Jc7g== X-Received: by 2002:a81:9f43:: with SMTP id w64-v6mr475434ywg.438.1530013563814; Tue, 26 Jun 2018 04:46:03 -0700 (PDT) Received: from ?IPv6:2620:10d:c0a3:20fb:7500:e7fb:4a6f:2254? ([2620:10d:c091:200::3:52b6]) by smtp.googlemail.com with ESMTPSA id m82-v6sm248794ywm.15.2018.06.26.04.46.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jun 2018 04:46:03 -0700 (PDT) Subject: Re: Invalid program counters and unwinding To: Florian Weimer , GCC , GNU C Library , Binutils , gnu-gabi@sourceware.org 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> From: Nathan Sidwell Message-ID: Date: Mon, 01 Jan 2018 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-SW-Source: 2018-q2/txt/msg00024.txt.bz2 On 06/26/2018 07:39 AM, Florian Weimer wrote: > On 06/26/2018 01:35 PM, Nathan Sidwell wrote: >> 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. I'm not sure at all. I remember needing to use nothrow somewhere that throw() didn't cut it, and could well have got the details wrong, and the compiler has moved on anyway. > 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. Hm, that seems contradictory ... nathan -- Nathan Sidwell