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 62167385AE6C for ; Tue, 9 Aug 2022 13:03:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 62167385AE6C 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 AQAAf9BxoM8qW_JiciALAA--.35310S2; Tue, 09 Aug 2022 21:03:39 +0800 (CST) Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mltQQVRDSCB2NV0gTG9vbmdBcmNoOiBhZGQgbW92?= =?UTF-8?Q?able_attribute?= To: Xi Ruoyao , "gcc-patches@gcc.gnu.org" Cc: WANG Xuerui , Youling Tang , Chenghua Xu , Huacai Chen , Jinyang He References: <90d2f698eaa2ef88712e9aef453b1deff197b533.camel@xry111.site> <44a2cb6f-b8b2-babb-bfcc-3dd17d8fce42@loongson.cn> <60bac545a09ee202d41421a596ac64a4cb83d89c.camel@xry111.site> <3aebe438b53e84eab24824f6cc79ae655cfb0f72.camel@xry111.site> <4789106a3b8ca37bd0f810b818eb14cae5fc9cac.camel@xry111.site> <76ddfa4a-6c7c-8c67-c6cd-4d6ae0bc87a5@xen0n.name> <069670e7-faf3-ecd4-be4f-3b0f8debb508@loongson.cn> <7c1d15a6-4e29-99b5-4b66-41af2fece9a6@loongson.cn> <6393bd75250c1cb46377b7eee4afd7db4bda7e25.camel@xry111.site> From: Lulu Cheng Message-ID: Date: Tue, 9 Aug 2022 21:03:38 +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: <6393bd75250c1cb46377b7eee4afd7db4bda7e25.camel@xry111.site> Content-Language: en-US X-CM-TRANSID: AQAAf9BxoM8qW_JiciALAA--.35310S2 X-Coremail-Antispam: 1UD129KBjvdXoWrtr15KFWruw48CFW8KF4xXrb_yoWkKwb_ZF 9Ygr92q3WjvF4Dta1UKFy5C392ya90gw1UJrWDJr12v3sxt3W5GFZ3tr95tF1fJayYyrW5 WrWYqF1rW34YgjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbxkFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8w A2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE3s 1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280 aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4x0x7Aq67IIx4 CEVc8vx2IErcIFxwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCY 02Avz4vE-syl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4 xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1D MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I 0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v2 6r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7VU1 g4S7UUUUU== X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Spam-Status: No, score=-5.0 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: Tue, 09 Aug 2022 13:03:44 -0000 在 2022/8/9 下午7:30, Xi Ruoyao 写道: > Sorry for late reply, I'm rebuilding my entire Linux system (from > scratch) for Glibc-2.36 and Binutils-2.39 update and I just reached the > mail client. > > On Mon, 2022-08-08 at 12:53 +0800, Lulu Cheng wrote: >> I still think it makes a little bit more sense to put attribute(model) >> and -mcmodel together. >> >> -mcmodel sets the access range of all symbols in a single fileand >> attribute (model) sets the >> >> accsess range of a single symbol in a file. For example >> __attribute__((model(normal/large/extreme))). > It might make sense, but then it would not be what we want for per-CPU > symbols. What we want here is "treat a local symbol as-if it's global", > while each code model may already treat local symbol and global symbol > differently. > > Disambiguation: here "local" means "defined in this TU", "global" > otherwise (not "local variable" in C). > > I'll send v6 with the name "addr_global" if no objection. > I am implementing the mode of cmodel=extreme. In this mode, the value of the relative offset is a signed 64-bit value, so this can solve the access problem of the variables of the kernel precpu. So I wonder if it is necessary to add another attribute like addr_global?