From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id A69993858D1E for ; Fri, 5 Aug 2022 07:19:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A69993858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from [10.20.4.52] (unknown [10.20.4.52]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9DxMM+QxOxigZcHAA--.28752S2; Fri, 05 Aug 2022 15:19:47 +0800 (CST) Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mltQQVRDSCB2NV0gTG9vbmdBcmNoOiBhZGQgbW92?= =?UTF-8?Q?able_attribute?= To: Xi Ruoyao , "gcc-patches@gcc.gnu.org" Cc: Youling Tang , Chenghua Xu , Huacai Chen , Jinyang He , Wang Xuerui References: <6cafbcdf79f77b73b9329f3e3a2f24ec85eda94d.camel@xry111.site> <-2muj1c-68saz6jhkcyw3jo1xp-1mgcvnkbqi2wjp6tue-qsso54-emxgu3-k85590-kpgox7-w67u6h3cai1l-5bi887dsgzsu-g4d7i7-wl316qxrucx4kv4on7-mnna36-iremg8-nwc5ot-9041t2-hu8nsl.1659495047941@email.android.com> <90d2f698eaa2ef88712e9aef453b1deff197b533.camel@xry111.site> <44a2cb6f-b8b2-babb-bfcc-3dd17d8fce42@loongson.cn> <60bac545a09ee202d41421a596ac64a4cb83d89c.camel@xry111.site> <3aebe438b53e84eab24824f6cc79ae655cfb0f72.camel@xry111.site> <4789106a3b8ca37bd0f810b818eb14cae5fc9cac.camel@xry111.site> From: Lulu Cheng Message-ID: Date: Fri, 5 Aug 2022 15:19:44 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <4789106a3b8ca37bd0f810b818eb14cae5fc9cac.camel@xry111.site> Content-Language: en-US X-CM-TRANSID: AQAAf9DxMM+QxOxigZcHAA--.28752S2 X-Coremail-Antispam: 1UD129KBjvJXoW7AFykuF4kJryxArWftFWxXrb_yoW8XFyUpF ZrJ3W0yFs7Cws7W3ykt3WkJrW3ua93Ja15try7Ka4F93ZxZry2yF4DKr1a9F1DZ34xA34a vwsIvw1DAFyUAaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUva14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I8E87Iv6xkF7I0E14v26r xl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0E x4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwACjI8F5V A0II8E6IAqYI8I648v4I1l7480Y4vEI4kI2Ix0rVAqx4xJMxk0xIA0c2IEe2xFo4CEbIxv r21lc2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I 0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWU AVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcV CY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv 67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyT uYvjfUwYFCUUUUU X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, BODY_8BITS, HTML_MESSAGE, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2022 07:19:54 -0000 在 2022/8/5 下午2:03, Xi Ruoyao 写道: > On Fri, 2022-08-05 at 12:01 +0800, Lulu Cheng wrote: >> 在 2022/8/5 上午11:45, Xi Ruoyao 写道: >> >> >> >> >>> On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote: >>> >>> >>> >>> >>> >>>> Or maybe we should just use a PC-relative addressing with 4 instructions >>>> instead of GOT for -fno-PIC? >>> Not possible, Glibc does not support R_LARCH_PCALA* relocations in >>> ld.so. So we still need a -mno-got (or something) option to disable GOT >>> for special cases like the kernel. >>> >>> >>> >>> >>> >>>> Both way consumes 16 bytes (4 instructions >>>> for PC-relative, 2 instructions and a 64-bit GOT entry for GOT) and PC- >>>> relative may be more cache friendly.   But such a major change cannot be >>>> backported for 12.2 IMO. >> >> >> >> >> I'm very sorry, my understanding of the precpu variable is wrong, >> I just read the code of the kernel you submitted, this precpu variable >> not only has a large offset but also has an uncertain address when compiling, >> so no matter whether it is addressed with pcrel Still got addressing needs >> dynamic relocation when loading. It seems that accessing through the got table >> is a better choice. >> >> The name movable is also very vivid to describe this function in the kernel, >> indicating that the address of the variable can be changed at will. >> >> But this name is more difficult to understand in gcc, I have no opinion on other, >> can this name be changed? > Yes, we don't need to be compatible with old vendor compiler IMO. > > > "force_got_access" as Xuerui suggested? Compared with these names, I think addr_global is better.