From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eastern.birch.relay.mailchannels.net (eastern.birch.relay.mailchannels.net [23.83.209.55]) by sourceware.org (Postfix) with ESMTPS id D14443858006 for ; Tue, 29 Dec 2020 14:04:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D14443858006 X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id EBDAF1E23DB; Tue, 29 Dec 2020 14:04:17 +0000 (UTC) Received: from pdx1-sub0-mail-a3.g.dreamhost.com (100-96-5-6.trex.outbound.svc.cluster.local [100.96.5.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 056CE1E2493; Tue, 29 Dec 2020 14:04:16 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a3.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Tue, 29 Dec 2020 14:04:17 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Whispering-Relation: 4eac85ea67da225f_1609250657303_3008269981 X-MC-Loop-Signature: 1609250657303:4108442718 X-MC-Ingress-Time: 1609250657302 Received: from pdx1-sub0-mail-a3.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a3.g.dreamhost.com (Postfix) with ESMTP id B58EE7E668; Tue, 29 Dec 2020 06:04:16 -0800 (PST) Received: from [192.168.1.111] (unknown [1.186.101.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a3.g.dreamhost.com (Postfix) with ESMTPSA id 90D287E667; Tue, 29 Dec 2020 06:04:14 -0800 (PST) Subject: Re: [PATCH 2/2] nonstring: _FORTIFY_SOURCE=3 using __builtin_dynamic_object_size To: Adhemerval Zanella , libc-alpha@sourceware.org Cc: fweimer@redhat.com, jakub@redhat.com References: <20201219063314.1409576-1-siddhesh@sourceware.org> <20201219063314.1409576-3-siddhesh@sourceware.org> <83dd37c5-68c3-8794-c317-e07ec7434246@linaro.org> X-DH-BACKEND: pdx1-sub0-mail-a3 From: Siddhesh Poyarekar Message-ID: Date: Tue, 29 Dec 2020 19:34:09 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <83dd37c5-68c3-8794-c317-e07ec7434246@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_NONE, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 14:04:21 -0000 On 12/28/20 11:06 PM, Adhemerval Zanella via Libc-alpha wrote: > > > On 19/12/2020 03:33, Siddhesh Poyarekar via Libc-alpha wrote: >> These fortified functions use, roughly, the following idiom to >> implement fortifications: >> >> if (__builtin_dynamic_object_size (obj) != -1) >> { >> __fortified_chk (); >> return; >> } >> __unfortified (); > > Reading the D93015, it should be: > > if (__builtin_dynamic_object_size (obj, 0 or 1) != -1ULL) > > right? Technically, 0, 1, 2 or 3 but we only use 0 and 1 for _FORTIFY_SOURCE at the moment. > > The __builtin_dynamic_object_size seems to be a 64-bit integer. > How does it play in 32-bit targets? Would clang optimize the check > when dynamic one need to be emitted? > It should work, but I'll confirm just the same. >> LLVM is currently unable to fold the conditional; a patch has been >> proposed[1] to fix this. >> >> Due to this limitation in llvm, these fortifications have a higher >> performance cost than those in the first patch. >> >> [1] https://reviews.llvm.org/D93015 > > I think you can state that this has been implemented on LLVM. Given that it's no longer an issue, I suppose it's OK to simply omit this? Siddhesh