From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dragonfly.ash.relay.mailchannels.net (dragonfly.ash.relay.mailchannels.net [23.83.222.51]) by sourceware.org (Postfix) with ESMTPS id 0E12F3858C53 for ; Mon, 23 May 2022 16:33:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0E12F3858C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org 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 70BBD2A2814; Mon, 23 May 2022 16:33:41 +0000 (UTC) Received: from pdx1-sub0-mail-a305.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E5DA72A2A46; Mon, 23 May 2022 16:33:40 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1653323621; a=rsa-sha256; cv=none; b=TrQnDNz0Nh1nUx08l/sZP92ZxN4oN0jBXq1STE6006CYBYTmM3yEfZexrJROjHikt5xi70 WR8eizitycJw45KreXs/nFwkWYcG0UOYS1n6Y/mWIR+AY3nJwJrRLxE59Qj/wK+j7j8Bx5 kiXRzA6KMmgieeBb/0dYFLQ8CAMnnuojZaHThiRoW+2Yce8FOmB24Dcr0qSnHJqoUGUrUr 3kpwUo2RC/JSpOAv8iuJNDTxfE+f01u8ozrFJR3ylBwzJlUMqgn6K9V6j9XP4tL8MxGtlj wwGgdv3rp6rCPlehgbDvEhSEu+8civ1Sh2mLjBwaMk7EmC81IFjnB3DmKb4mTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1653323621; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LoxD8p90cyCS0lFHbkPCd7g515eZKPx+4DcwCi6En9g=; b=kVXbzHW1AKY1/SEdQdfXuOp0QLriGCpQVmtGPfZi6U3/o3hX+YE+g31YnwlMlvR3Z5TBDW vb0lqQC7lyq+s4kDteIOPku7ZeKkZnhxfRKPMLCi7ECYR+8CggRr9/Ey1L7xdr/OH2F60U UBXJg8eTyCc9OAZN17s/YOY+QAIl5AQkU2r2nLK3/LnFxDIc39ytvUAW6vsJXau1/CFLeX 59K6RJfMjfDj5F3AMRj6FOVAeBLUT2l7uZiYZYQqy7HOex85p12XKwRycf7OhmRFrYyOCD 2cBEOPlCstr3rZGgDCPSeAZaz4Qhyj5g5/76aeqtIBZStuo9A7Meg0Zm8iD/2A== ARC-Authentication-Results: i=1; rspamd-54dc6fd65d-tpdgm; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Snatch-Chemical: 463501cc40c9c316_1653323621257_3268045685 X-MC-Loop-Signature: 1653323621257:994008490 X-MC-Ingress-Time: 1653323621257 Received: from pdx1-sub0-mail-a305.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.124.238.93 (trex/6.7.1); Mon, 23 May 2022 16:33:41 +0000 Received: from [192.168.1.174] (unknown [1.186.122.67]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a305.dreamhost.com (Postfix) with ESMTPSA id 4L6NDy6TLnz2Y; Mon, 23 May 2022 09:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1653323620; bh=LoxD8p90cyCS0lFHbkPCd7g515eZKPx+4DcwCi6En9g=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=XeAMAfbGUlpmWt9n84eYcgLBbODSS/RgHGHT/eBpiZ0IJESv/ENdPWZIHiHTv/fIt AFNw+1T12M3ihknAeekw6HI1JplWeyPcmdnlIcKqDZu22KmdsRafGTOZRL2O5qJuZd jswwzFMya0eB4mbqcx3U2pdpqT4Jk8f+VIJsMa3ePj8Yslz70Zmp6ryN0NC93GSlS/ OoAhC1pIdVE4fUzftIviuKFw0/Z+vQRGbnGWaFJdXniPV8uhWoTvrGEqND8YhHqeWE CySFW3PRbL217ee8fHC/oueddGXjRQist37vpqneEVKZSNIj9PMbATevP+kdNGHdlZ /mMN1oBxXlynA== Message-ID: Date: Mon, 23 May 2022 22:03:33 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH v3] elf: Rewrite long RESOLVE_MAP macro to a debug friendly function Content-Language: en-US To: Adhemerval Zanella , Fangrui Song Cc: Nicholas Guriev , libc-alpha@sourceware.org References: <20220514224849.d7isxwcxnxoo3jhc@google.com> <20220522222425.hk5vde2erkyadxol@google.com> <94dbef38-5719-13f6-43a1-9a63367e217e@linaro.org> <92df96d2-1e71-53eb-7878-636f52913d07@gotplt.org> <9db7a4b9-7b2a-78fd-a42e-9f8470060ce2@linaro.org> From: Siddhesh Poyarekar In-Reply-To: <9db7a4b9-7b2a-78fd-a42e-9f8470060ce2@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3032.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_SBL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Mon, 23 May 2022 16:33:47 -0000 On 23/05/2022 21:52, Adhemerval Zanella wrote: > From ed159672eb3cd650a32b7e5cb4d5ec1fe0e63802 I take that even always_inline > might fail for some reason. So we need to keep using always_inline on function > that need to be inline to get a compiler warning if it can not be done. > > I think by using -Winline with stardand C99 static inline, besides being > slight more portable code is also less error prone (since it is one less > annotation to take care of). It would be slight better to setup -Winline > per TU, instead of global since we only need always_inline semantic for > specific usages. > > In the end I think both a pretty equivalent. That is surprising, and kinda defeats the "always" in the always_inline. The documentation for the attribute also states that failure to inline a function is diagnosed as an error[1], except when the function is called indirectly and maybe some more context is needed for ed159672eb3cd650a32b7e5cb4d5ec1fe0e63802 to understand the nature of the warnings. So I can't agree yet that it's equivalent, but I do agree that the always_inline semantic is for specific use cases. Thanks, Siddhesh [1] https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html