From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <0x66726565@gmail.com> Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by sourceware.org (Postfix) with ESMTPS id E5D713858005 for ; Wed, 28 Oct 2020 05:47:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E5D713858005 Received: by mail-io1-xd32.google.com with SMTP id u62so4118014iod.8 for ; Tue, 27 Oct 2020 22:47:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LGQYuLVIHqD8+cnb/OiNMrB648vw4OPsMH65nNaiujI=; b=tuSC1OaYmbYYiQhhTJ4tBKpMIGttsX7Fj9COQ8GuPMSi0DmWqlmo+0EWogDRpUZTVs NWJmtTXo8DKZKDA4FsrzATYPNlKcosnW6rhiRcgOJNpj09jbmAvNug7dhPsXdJhSY8aY wP2fIC6c6gqKfADn9kTE8AXgUd2mU5oc/fHUAehKBT6aduD61Plx/Sr6leXWsRJp82jE NV+f073TAX3GHqPUzrlQObaJ3b/g/NoJCt2k/9pb2yqTzBmbgUsTj7L2wDwTWRZW/0Vv d87FwJB8cG6/rLmTBMyfw/+Cl+y4xDuO5wGd/+fcJ5jWllDm0kN5LIUcv+jZZWgD+hxL d4Zw== X-Gm-Message-State: AOAM533Sh8Cdbu/j4pxvlfbqSyadHabggOBsmMwPlI5/2+TgjqI/tuiC 8MiHsZGshnFHerDqYBkK6aXwQUUKynug0MxYgg== X-Google-Smtp-Source: ABdhPJx7I/vBwe8IUu5RBHwACjr7ItlJI5djc2oDT4EtxnivHPScYT4V0g4D/mhB+V9hoblEQyCBT7Og0JVWgel4SGs= X-Received: by 2002:a05:6602:1216:: with SMTP id y22mr4973930iot.53.1603864079171; Tue, 27 Oct 2020 22:47:59 -0700 (PDT) MIME-Version: 1.0 References: <25b5791b-5368-7a78-f80d-5ceb2b618d72@linaro.org> In-Reply-To: <25b5791b-5368-7a78-f80d-5ceb2b618d72@linaro.org> From: Tadeus Prastowo <0x66726565@gmail.com> Date: Wed, 28 Oct 2020 06:47:47 +0100 Message-ID: Subject: Re: raise() marked __leaf__ is not C-compliant? To: Adhemerval Zanella Cc: "libc-help@sourceware.org" Content-Type: multipart/mixed; boundary="000000000000b541a505b2b4b4f1" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URI_DOTEDU autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 05:48:02 -0000 --000000000000b541a505b2b4b4f1 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 27, 2020 at 7:50 PM Adhemerval Zanella wrote: > > On 27/10/2020 13:57, Tadeus Prastowo via Libc-help wrote: > > > > My understanding is that if my single-threaded program installs a > > signal handler using signal() and the handler is executed as a result > > of calling raise(), then the handler has a defined behavior when the > > handler accesses any object with static storage duration even though > > the object is not qualified using volatile and not of type > > sig_atomic_t. > > > > If my understanding is incorrect, I would like to have some pointer to > > parts of the C standard that say so. > > Unfortunately this is not fully correct, specially if you accessing the > object outside the signal handler. As you have noticed in your example, > compiler can assume the variable 'terminated' won't be modified outside > the function and apply optimization that avoid read its value from > memory (most likely GCC will optimize out the '!terminated'). However, the compiler cannot assume that the variable `terminated' won't be modified outside the loop if the loop calls a function whose definition the compiler does not see (e.g., the raise() function defined by glibc). Otherwise, the compiler is wrong if the loop calls a function defined in another translation unit because the function may modify `terminated'. > One of the best didactic explanation I have for this is from [1]. > > [1] https://wiki.sei.cmu.edu/confluence/display/c/SIG31-C.+Do+not+access+shared+objects+in+signal+handlers Thank you for the reference. I have studied it but found no pointer to parts of the C standard that says that it is an undefined behavior to call a signal handler synchronously using raise() on a normal execution path (i.e., not from within another signal handler, which certainly is undefined behavior as noted in "undefined behavior 131"). I know that the safest thing to do is always to qualify such a variable with `volatile', but I think it is valid to not do so for the cases that are not stated as undefined/unspecified/implementation-defined behavior by the C standard. That is why I ask for a pointer to parts of the C standard if indeed calling a signal handler synchronously using raise() on a normal execution path is an undefined behavior. After further thought, I found out that the problem is not glibc-2.30 marking raise() with __leaf__ but the file-scope limitation of `terminated'. As I already mentioned, since `terminated' has a file-scope, the compiler can assume that `terminated' will not be modified by a function defined in another translation unit. And hence, the compiler is correct in optimizing out the `!terminated'. Once `terminated' has a global scope, the compiler correctly does not optimize it out as exemplified by the attached program. So, marking raise() with __leaf__ does not make raise() non-compliant with the C standard. Thank you for answering my question. -- Best regards, Tadeus --000000000000b541a505b2b4b4f1 Content-Type: text/x-csrc; charset="US-ASCII"; name="raise.c" Content-Disposition: attachment; filename="raise.c" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kgsz5mco0 LyogQ29tcGlsZSB0aGlzIGFzIGZvbGxvd3M6CiAqICAgZ2NjIC1PMCAtbyByYWlzZSByYWlzZS5j CiAqIFRoZSBDIHN0YW5kYXJkIG9uIHNpZ25hbCgpIGd1YXJhbnRlZXMgdGhhdCB0aGUgZXhlY3V0 aW9uIG9mIHJhaXNlIHdpbGwKICogdGVybWluYXRlLgogKgogKiBDb21waWxlIHRoaXMgYXMgZm9s bG93czoKICogICBnY2MgLU9zIC1vIHJhaXNlIHJhaXNlLmMKICogVGhlIEMgc3RhbmRhcmQgb24g c2lnbmFsKCkgZ3VhcmFudGVlcyB0aGF0IHRoZSBleGVjdXRpb24gb2YgcmFpc2Ugd2lsbAogKiB0 ZXJtaW5hdGUuCiAqCiAqIENvbXBpbGUgdGhpcyBhcyBmb2xsb3dzOgogKiAgIGdjYyAtTzIgLW8g cmFpc2UgcmFpc2UuYwogKiBUaGUgQyBzdGFuZGFyZCBvbiBzaWduYWwoKSBndWFyYW50ZWVzIHRo YXQgdGhlIGV4ZWN1dGlvbiBvZiByYWlzZSB3aWxsCiAqIHRlcm1pbmF0ZS4KICovCgojaW5jbHVk ZSA8c2lnbmFsLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHRpbWUuaD4KCmludCB0 ZXJtaW5hdGVkOwoKc3RhdGljIHZvaWQgaGFuZGxlcihpbnQgc2lnbm8pCnsKICB0ZXJtaW5hdGVk ID0gMTsKfQoKaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KSB7CiAgdW5zaWduZWQgdG90 YWwgPSAwLCBkZWx0YSA9IGRyYW5kNDgoKSA+PSBhcmdjID8gMSA6IDA7CiAgLyogQXQgcnVudGlt ZSwgZGVsdGEgd2lsbCBiZSAwIGFzIGFyZ2MgaXMgb25lICovCgogIHNpZ25hbChTSUdVU1IxLCBo YW5kbGVyKTsKCiAgLyogVGhpcyBpcyBhbiBpbmZpbml0ZSBsb29wIHVubGVzcyB0ZXJtaW5hdGVk IGlzIDEgYXMgZGVsdGEgaXMgc3VyZWx5IDAgKi8KICBmb3IgKGludCBpID0gMDsgIXRlcm1pbmF0 ZWQgJiYgaSA8IDEwMDsgaSArPSBkZWx0YSkgewogICAgdG90YWwgKz0gaTsKICAgIHJhaXNlKFNJ R1VTUjEpOwogIH0KICAKICByZXR1cm4gdG90YWw7Cn0K --000000000000b541a505b2b4b4f1--