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 4BFC43858407 for ; Fri, 5 Aug 2022 04:01:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4BFC43858407 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 AQAAf9Axis0AluximEkHAA--.23494S2; Fri, 05 Aug 2022 12:01:04 +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> From: Lulu Cheng Message-ID: Date: Fri, 5 Aug 2022 12:01:03 +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: Content-Language: en-US X-CM-TRANSID: AQAAf9Axis0AluximEkHAA--.23494S2 X-Coremail-Antispam: 1UD129KBjvJXoW7XF4xuFWkXF4xKFyxCFy5twb_yoW8JrW5pF WDJ3WIyF4kGw4xG3ykt3W8JFWfCa93Aa15try7Ga4F9wnxWr12yF4DKw1a9ryDX3yxA34a vw429w1DAFy5AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvS14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I8E87Iv6xkF7I0E14v26r xl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0E x4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwACjI8F5V A0II8E6IAqYI8I648v4I1l7480Y4vEI4kI2Ix0rVAqx4xJMxk0xIA0c2IEe2xFo4CEbIxv r21lc2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I 0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWU AVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcV CY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280 aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43 ZEXa7VU1g4S7UUUUU== 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 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 04:01:11 -0000 在 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?