From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <0x66726565@gmail.com> Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) by sourceware.org (Postfix) with ESMTPS id 670E43846079 for ; Tue, 27 Oct 2020 16:57:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 670E43846079 Received: by mail-io1-xd31.google.com with SMTP id k6so2301334ior.2 for ; Tue, 27 Oct 2020 09:57: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:from:date:message-id:subject:to; bh=1YkR1rt3kAXT9GIolljn8OwcEJ3wFoZ+blYpUdU8qiI=; b=hQ/vV5DfVyToJ+M8SeAKwLVn41EOw+FWm728uWdM1VU4BsQSHoeQMK+7jn/Dm73cW0 l0bnOvK3sHbbeG7rlLhYaiy3aOWBlhMcy2D+CNKBrjAem57lyrZBtFaCWAH8TDOTl65k VR125VIlXjx1SkOkE+U0otsIupPk5iy4DUpoA9QjUodwUhT5TA9bebpJlzEBTw8lOf9X xFLUku2KHbN8VbH2bP1+ExmL1/4QyZniU3qEBm7gJX1zp0ehKBZ7Ns3ZY0wLJ7ZybcwU +gUJ6Le6YElJZsz9WkZUgQdeIFY43qre3dbTavgY7/HN9wWTK9GvBTyhNyDCLax77Jbi IwyA== X-Gm-Message-State: AOAM530U9eH/cqNSBF1RFsrIaXU0NhPLS2g1zF1PSvmBvwTF7ZdJ+/7X O73ZB5D0Cnbql74U26HGSAFm/EEty/DG7aV7f1lpUrAwAA== X-Google-Smtp-Source: ABdhPJz6ebzMRUPoR0WO/K5tHE+fDX1sz12r9FwoZRdB4JqsY9DLJaUeMTD0e0MBrBTYS5+yQYAMci2vfKU75HEdITc= X-Received: by 2002:a05:6638:16cb:: with SMTP id g11mr3486214jat.84.1603817878513; Tue, 27 Oct 2020 09:57:58 -0700 (PDT) MIME-Version: 1.0 From: Tadeus Prastowo <0x66726565@gmail.com> Date: Tue, 27 Oct 2020 17:57:47 +0100 Message-ID: Subject: raise() marked __leaf__ is not C-compliant? To: libc-help@sourceware.org Content-Type: multipart/mixed; boundary="000000000000ef072005b2a9f214" X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: Tue, 27 Oct 2020 16:58:01 -0000 --000000000000ef072005b2a9f214 Content-Type: text/plain; charset="UTF-8" Hello, To quote C18 on the signal() function (https://web.archive.org/web/20181230041359/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf), Section 7.14.1.1 Paragraph 5: If the signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler refers to any object with static or thread storage duration that is not a lock-free atomic object other than by assigning a value to an object declared as volatile sig_atomic_t End quote. 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. Otherwise, why glibc 2.30 implements raise() on x86_64 by using the GCC function attribute __leaf__ when GCC says (https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes): Note that leaf functions might indirectly run a signal handler defined in the current compilation unit that uses static variables. Similarly, when lazy symbol resolution is in effect, leaf functions might invoke indirect functions whose resolver function or implementation function is defined in the current compilation unit and uses static variables. There is no standard-compliant way to write such a signal handler, resolver function, or implementation function, and the best that you can do is to remove the leaf attribute or mark all such static variables volatile. End quote. I see the use of the __leaf__ attribute by glibc 2.30 by reading /usr/include/signal.h, finding __THROW, and then reading /usr/include/sys/cdefs.h for __THROW definition, which expands to include the __leaf__ attribute. With glibc-2.30 raise() being marked __leaf__, the attached C program has an undefined behavior because it terminates when compiled with GCC using either -O0 or -Os but enters an infinite loop when using -O2. Should glibc 2.30 be compiled in a specific way to have the defined behavior guaranteed by the C standard? If yes, what configure options should be used? Thank you. -- Best regards, Tadeus --000000000000ef072005b2a9f214 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_kgs7pg140 LyogQ29tcGlsZSB0aGlzIGFzIGZvbGxvd3M6CiAqICAgZ2NjIC1PMCAtbyByYWlzZSByYWlzZS5j CiAqIFRoZSBDIHN0YW5kYXJkIG9uIHNpZ25hbCgpIGd1YXJhbnRlZXMgdGhhdCB0aGUgZXhlY3V0 aW9uIG9mIHJhaXNlIHdpbGwKICogdGVybWluYXRlLgogKgogKiBDb21waWxlIHRoaXMgYXMgZm9s bG93czoKICogICBnY2MgLU9zIC1vIHJhaXNlIHJhaXNlLmMKICogVGhlIEMgc3RhbmRhcmQgb24g c2lnbmFsKCkgZ3VhcmFudGVlcyB0aGF0IHRoZSBleGVjdXRpb24gb2YgcmFpc2Ugd2lsbAogKiB0 ZXJtaW5hdGUuCiAqCiAqIENvbXBpbGUgdGhpcyBhcyBmb2xsb3dzOgogKiAgIGdjYyAtTzIgLW8g cmFpc2UgcmFpc2UuYwogKiBUaGUgQyBzdGFuZGFyZCBvbiBzaWduYWwoKSBndWFyYW50ZWVzIHRo YXQgdGhlIGV4ZWN1dGlvbiBvZiByYWlzZSB3aWxsCiAqIHRlcm1pbmF0ZS4gIFVuZm9ydHVuYXRl bHksIGdsaWJjLTIuMzAgcmFpc2UoKSBpcyBtYXJrZWQgX19sZWFmX18sIGFuZCBzbywgdGhlCiAq IGV4ZWN1dGlvbiB3b24ndCB0ZXJtaW5hdGUgb24gYSB4ODZfNjQgbWFjaGluZS4KICovCgojaW5j bHVkZSA8c2lnbmFsLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHRpbWUuaD4KCnN0 YXRpYyBpbnQgdGVybWluYXRlZDsKCnN0YXRpYyB2b2lkIGhhbmRsZXIoaW50IHNpZ25vKQp7CiAg dGVybWluYXRlZCA9IDE7Cn0KCmludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikgewogIHVu c2lnbmVkIHRvdGFsID0gMCwgZGVsdGEgPSBkcmFuZDQ4KCkgPj0gYXJnYyA/IDEgOiAwOwogIC8q IEF0IHJ1bnRpbWUsIGRlbHRhIHdpbGwgYmUgMCBhcyBhcmdjIGlzIG9uZSAqLwoKICBzaWduYWwo U0lHVVNSMSwgaGFuZGxlcik7CgogIC8qIFRoaXMgaXMgYW4gaW5maW5pdGUgbG9vcCB1bmxlc3Mg dGVybWluYXRlZCBpcyAxIGFzIGRlbHRhIGlzIHN1cmVseSAwICovCiAgZm9yIChpbnQgaSA9IDA7 ICF0ZXJtaW5hdGVkICYmIGkgPCAxMDA7IGkgKz0gZGVsdGEpIHsKICAgIHRvdGFsICs9IGk7CiAg ICByYWlzZShTSUdVU1IxKTsKICB9CiAgCiAgcmV0dXJuIHRvdGFsOwp9Cg== --000000000000ef072005b2a9f214--