From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115799 invoked by alias); 26 Jun 2018 11:35:45 -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 115761 invoked by uid 89); 26 Jun 2018 11:35:44 -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=HX-Received:sk:m1-v6mr, H*f:sk:8a147f0, H*i:sk:8a147f0 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-f178.google.com Received: from mail-yw0-f178.google.com (HELO mail-yw0-f178.google.com) (209.85.161.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Jun 2018 11:35:43 +0000 Received: by mail-yw0-f178.google.com with SMTP id i143-v6so4469403ywc.9; Tue, 26 Jun 2018 04:35:43 -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=7XEi50KIEfzwyCM+Tw6zrT08v2eYyarOY+U/071AirA=; b=rata6uGI/X/qFPAj2UeTBLNfZ9GqA1w11GqUldRHMYxllKSKvvrEJim6cVIYCZaFB5 ohSxfgGh9GIHZZzS9WbA5+DVrfbavG8umk+xmezng1+GUsV6e3TTUreUIBomtnONgGar MKUVWD0g/QTKKSs26oWsc/F1xD6PE521W079+1Q92r8YjMrEuvwJ9D6hKDXvbIGAcl7O oVVfbU7YoZk/IM9UyMsmm5+Qm+WWEmcC6WcbqrILthR9RzOyGu5K8Bgs8S33cjRoPcBZ +O2yI5G3Ak1tX30ADYeF9eR4iByVjHp0nb/DAckxYHSob/prIscPDVv9eTgIgr+S+7S7 5Cmw== 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=7XEi50KIEfzwyCM+Tw6zrT08v2eYyarOY+U/071AirA=; b=ZGF4kOJOPiQah/1WqL5Xli4RYo8Ur8TUNFH8PbQHBv3aRiaHCmq6DqRWj9ND/Hj7fH 7abrwy/XUEH1bXh0TXMlq4y/vOGd8lIm9g6LbCNXqMpL1Gv44znSWlWWrZlQNx42bxQP DWzK197KklcwDLJuD+fhccJZgd02Qxekt5qBEXvQ1P8mPgAxKZWB/5LsQn0rsVvzzAQ5 PqGnz8xNUDd2OT8YU0W/uvi0PD6Ui0zxjglYWxMjwvOjp7LgySaz7gEVGnuCxrjVbH/P 5BbmRxLgE45nz0jpLm8hKL8zh1wZ23b7xYmHwZ9eFzP7FksY3p5FlgisAAt9cnGEA2y0 Wlfg== X-Gm-Message-State: APt69E1xx4mSVXvzGBIOdbK8lWvUVqPUEPNT1/ZMJpuOBeWBafV34Wrn rWTX8rhbZXDRL4jluA+a22M= X-Google-Smtp-Source: AAOMgpcMyXmnGchXexOOnp4qtNXaPAGyuWjQ8wrzSwtw+5nnL9nBO4/sDbHeZAXszYclbm13/AeLWw== X-Received: by 2002:a81:c701:: with SMTP id m1-v6mr501573ywi.334.1530012941621; Tue, 26 Jun 2018 04:35:41 -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 y4-v6sm463750ywe.48.2018.06.26.04.35.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jun 2018 04:35:40 -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: <8a147f05-509f-16a0-f108-9e76bcae4ea9@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-SW-Source: 2018-q2/txt/msg00021.txt.bz2 On 06/26/2018 07:21 AM, Florian Weimer wrote: > GCC doesn't do this AFAIK, but it's theoretically possible not to > preserve the return address for a noreturn function.  But that would be > very bad for exception handling, so let's hope compilers don't do this. I'd forgotten about noreturn. Such functions may terminate by throwing an exception (and for our purposes I think pthread_cancel implementatio is sufficiently exception-like): from C++ std: [dcl.attr.noreturn]/2 [ Note: The function may terminate by throwing an exception. — end note ] and from doc/extend.texi: 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. nathan -- Nathan Sidwell