From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31]) by sourceware.org (Postfix) with ESMTPS id CAD5F3858D37 for ; Fri, 5 Aug 2022 07:41:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CAD5F3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=xen0n.name Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xen0n.name DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1659685285; bh=PEQpI2lRO4BtUqAygYzFWUagrfZop4d0ARpkzRIEldk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=FANBETA0ghIP9LAWQoIv/x4r0r7ffvt5ET64quiE1n30WtN3NxEmOHRMcAm0H9Xjv zvAVH/a31McSU6k2AMBXZ16fuQY5O48hb6QONsTWuwrac2uYpUrbdiIKo4UFzr+I9+ Dc4DMZK1hSUuMvKpr2MZi6WZfjXr3Wwi3fSxRt4M= Received: from [100.100.57.219] (unknown [220.248.53.61]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailbox.box.xen0n.name (Postfix) with ESMTPSA id 1F9B16010B; Fri, 5 Aug 2022 15:41:25 +0800 (CST) Message-ID: <76ddfa4a-6c7c-8c67-c6cd-4d6ae0bc87a5@xen0n.name> Date: Fri, 5 Aug 2022 15:41:24 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:105.0) Gecko/20100101 Thunderbird/105.0a1 Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mltQQVRDSCB2NV0gTG9vbmdBcmNoOiBhZGQgbW92?= =?UTF-8?Q?able_attribute?= Content-Language: en-US To: Lulu Cheng , Xi Ruoyao , "gcc-patches@gcc.gnu.org" Cc: Youling Tang , Chenghua Xu , Huacai Chen , Jinyang He 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: WANG Xuerui In-Reply-To: X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, NICE_REPLY_A, SPF_HELO_NONE, 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:41:36 -0000 On 2022/8/5 15:19, Lulu Cheng wrote: > > > 在 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. Actually if "model(...)" can be implemented I'd prefer a descriptive word/phrase inside model(). Because it may well be the case that more peculiar ways of accessing some special data will have to be supported in the future, and all of them are kind of "data models" so we'd be able to nicely group them with model(...). Otherwise I actually don't have a particularly strong opinion, aside from "movable" which IMO should definitely not be taken.