From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-99236-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 637 invoked by alias); 14 Jan 2019 20:29:20 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 626 invoked by uid 89); 14 Jan 2019 20:29:19 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=
X-HELO: mail-qt1-f175.google.com
Return-Path: <carlos@redhat.com>
Subject: Re: Fwd: What can a signal handler do with SIGSTKSZ?
To: Zack Weinberg <zackw@panix.com>,
 Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: GNU C Library <libc-alpha@sourceware.org>
References: <e4215c6e-e8a4-a9b6-d88f-3c54e262711a@redhat.com>
 <CAKCAbMiCaBst_ofjKkH3Ck1CoOV86wPKv3QSkC89XW_zu=1BLA@mail.gmail.com>
 <CAKCAbMiWEk6UZJZPQb9h6GOJ5tWACMUzgg5dUra0ET4bESMotQ@mail.gmail.com>
 <874lafezhe.fsf@oldenburg2.str.redhat.com>
 <CAKCAbMgRFet-aM4wdhr5i+ezbDKxcNXnhTO6yRASGbznk__oZg@mail.gmail.com>
 <87sgxzdjl4.fsf@oldenburg2.str.redhat.com>
 <CAKCAbMig4Ze7V+WsNOvwERZDzbACZPQ_btc1wR69EXNZCc+J7g@mail.gmail.com>
 <61925098-4669-b478-9baf-644818d26a44@arm.com>
 <32971978-77ca-57f4-2524-560f53008be4@linaro.org>
 <CAKCAbMjd-zL5kcoLZJKz++NkAnB5vS_yE-D6QAqicosdythu9w@mail.gmail.com>
From: Carlos O'Donell <carlos@redhat.com>
Openpgp: preference=signencrypt
Message-ID: <bdbd96fd-e764-3d19-4ad8-4352b31109d2@redhat.com>
Date: Mon, 14 Jan 2019 20:29:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <CAKCAbMjd-zL5kcoLZJKz++NkAnB5vS_yE-D6QAqicosdythu9w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2019-01/txt/msg00306.txt.bz2

On 1/14/19 11:34 AM, Zack Weinberg wrote:
> For this new interface, the backward compatibility concerns I raised
> regarding what you can do in MINSIGSTKSZ don't necessarily apply, and
> it would make sense for it to be truly a minimum.  I would suggest we
> define "minimum" in terms of what the C standard - not POSIX - allows
> you to do in a signal handler, which is almost nothing:  you're
> guaranteed to have enough space in sysconf(_SC_MINSIGSTKSZ) for this:
> 
>     static volatile sig_atomic_t signal_flag = 0;
>     static void handler(int unused)
>     {
>        flag = 1;
>     }
> 
> and this:
> 
>    static atomic_uint signal_count = 0;
>    static void handler (int unused)
>    {
>       atomic_fetch_add (&signal_count, 1);
>    }

By my reading we'd also have to support:  abort, _Exit, 
quick_exit, and signal.

What I'm not quite sure about is that errno has visible
changes from these functions, particularly signal failing
and if we must also exercise writing to a TLS errno.

-- 
Cheers,
Carlos.