From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by sourceware.org (Postfix) with ESMTPS id 37B733858407 for ; Sat, 30 Jul 2022 06:04:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 37B733858407 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D2F97B81982 for ; Sat, 30 Jul 2022 06:04:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C7C9C433B5 for ; Sat, 30 Jul 2022 06:04:18 +0000 (UTC) Received: by mail-vk1-f172.google.com with SMTP id y129so3225375vkg.5 for ; Fri, 29 Jul 2022 23:04:18 -0700 (PDT) X-Gm-Message-State: AJIora/mU6msYDJOWt17imUoV5mUuKF85R/+Cv/3JIR47soVktXEqt/C 8K+U5upx74jztX04PwwctMhUVOLcUQL7EXZDj1E= X-Google-Smtp-Source: AGRyM1vX7hb63R5DMXgXe9RD/qJontKPO2EPEZYwgfPJnJn9lb3DEEfNupd7cQWET5U5NVAGGlPtzrjQADw1q3RahKk= X-Received: by 2002:a1f:9d13:0:b0:376:7f81:9b85 with SMTP id g19-20020a1f9d13000000b003767f819b85mr2995556vke.18.1659161057406; Fri, 29 Jul 2022 23:04:17 -0700 (PDT) MIME-Version: 1.0 References: <9b6b0e68cfb7e87ae961ef8a7bb7987f534da19c.camel@xry111.site> <285f23f7-55d6-e185-dbd9-f69ed09e4286@loongson.cn> In-Reply-To: <285f23f7-55d6-e185-dbd9-f69ed09e4286@loongson.cn> From: Huacai Chen Date: Sat, 30 Jul 2022 14:03:59 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] LoongArch: add addr_global attribute To: Lulu Cheng Cc: Xi Ruoyao , gcc-patches@gcc.gnu.org, Jinyang He , Xu Chenghua , Youling Tang , Wang Xuerui Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, 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 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: Sat, 30 Jul 2022 06:04:23 -0000 Hi, Lulu, On Sat, Jul 30, 2022 at 11:13 AM Lulu Cheng wrote: > > > =E5=9C=A8 2022/7/30 =E4=B8=8A=E5=8D=881:17, Xi Ruoyao =E5=86=99=E9=81=93: > > Change v2 to v3: > - Disable section anchor for addr_global symbols. > - Use -O2 in test to make sure section anchor is disabled. > > -- > > Background: > https://lore.kernel.org/loongarch/d7670b60-2782-4642-995b-7baa01779a66@lo= ongson.cn/T/#e1d47e2fe185f2e2be8fdc0784f0db2f644119379 > > Question: Do you have a better name than "addr_global"? > > I think the name can be changed to "get_through_got". What do you think o= f it? Is this the same thing as "movable" once we used internally? Huacai > > Alternatives: > > 1. Just use "-mno-explicit-relocs -mla-local-with-abs" for kernel > modules. It's stupid IMO. > 2. Implement a "-maddress-local-with-got" option for GCC and use it for > kernel modules. It seems too overkill: we might create many unnecessary > GOT entries. > 3. For all variables with a section attribute, consider it global. It > may make sense, but I just checked x86_64 and riscv and they don't do > this. > 4. Implement -mcmodel=3Dextreme and use it for kernel modules. To me > "extreme" seems really too extreme. > 5. More hacks in kernel. (Convert relocations against .data..percpu with > objtool? But objtool is not even implemented for LoongArch yet.) > > Note: I'll be mostly AFK in the following week. My attempt to finish > the kernel support for new relocs before going AFK now failed miserably > :(. > > -- >8 -- > > A linker script and/or a section attribute may locate a local object in > some way unexpected by the code model, leading to a link failure. This > happens when the Linux kernel loads a module with "local" per-CPU > variables. > > Add an attribute to explicitly mark an variable with the address > unlimited by the code model so we would be able to work around such > problems. > > > Others I think are ok.