From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 846A43849AD4 for ; Tue, 30 Apr 2024 11:30:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 846A43849AD4 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 846A43849AD4 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=114.242.206.163 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714476641; cv=none; b=pozoJxsK75Ofs7JfJBdTeZLtC2O6bkyLWhyPQZQxqaVGfsmffbjMcBf719Kn6Vs8U4Q35pPoSzW9im7yrjJLVjttmRcE6/b/ylKE+PDGq+bSZOfe+0SnG/0tPfPH8Ov2KoIAhM06zT8B5hSFW2Q62UA5Nk3RSIBSLVgiLE57hhE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714476641; c=relaxed/simple; bh=x9jfGml2fF6FRLmGx0NdTy49VGg32jlZ0N7i+7WFEzs=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=OQzuF79Q4TC1KInBkWbkN1wN6nNL/UijLli2iVW6sikzVGH7pNovucTXoXfoIiSRMs99aYSKDPW4FEM7dWoK1QZZ/eev86aXkW7OUGLTglArMLfSz3slYOOpOlb8xTsqLis23erhi6zcKp/yA0JRJ4q4jHCzElqMcDeMUYlY57U= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from loongson.cn (unknown [10.20.4.171]) by gateway (Coremail) with SMTP id _____8CxJvBa1jBmaWUFAA--.17791S3; Tue, 30 Apr 2024 19:30:34 +0800 (CST) Received: from [10.20.4.171] (unknown [10.20.4.171]) by localhost.localdomain (Coremail) with SMTP id AQAAf8BxPN5X1jBmfR4LAA--.26821S3; Tue, 30 Apr 2024 19:30:32 +0800 (CST) Subject: Re: [PATCH v2] BFD: Fix the bug of R_LARCH_AGLIN caused by discard section To: Fangrui Song , hejinyang@loongson.cn Cc: Alan Modra , binutils@sourceware.org, xuchenghua@loongson.cn, chenglulu@loongson.cn, liuzhensong@loongson.cn, cailulu@loongson.cn, xry111@xry111.site, i.swmail@xen0n.name, maskray@google.com, luweining@loongson.cn, wanglei@loongson.cn References: <20240322082915.3900449-1-mengqinggang@loongson.cn> <3f357195-d95d-4215-cbfb-d9259f660d45@loongson.cn> From: mengqinggang Message-ID: <4777a681-4d8c-9687-ef0a-85f9243b3dcd@loongson.cn> Date: Tue, 30 Apr 2024 19:30:31 +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-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8BxPN5X1jBmfR4LAA--.26821S3 X-CM-SenderInfo: 5phqw15lqjwttqj6z05rqj20fqof0/ X-Coremail-Antispam: 1Uk129KBj93XoWxCFyrtr1xArW5XrWxXrykXrc_yoW5Cw15pa 4YkF4UKw45JF1xGw4Iq3WjvF1I9anaqFWrWrnxGw18ZF9xZFyfKanrtryY9a47Gr9YyF45 Xw12vayUu3WqyacCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUvIb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r106r15M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv 67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07 AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02 F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GF ylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r 4j6F4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07j8 yCJUUUUU= X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,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 List-Id: 在 2024/4/20 上午1:52, Fangrui Song 写道: >>> On Thu, Apr 18, 2024 at 11:04 PM Fangrui Song wrote: >>> I should make it clear that I think this R_LARCH_ALIGN referencing >>> STT_SECTION with addend align+256*align_limit representation is >>> questionable. >>> Why do you break the regular semantics of STT_SECTION relocatable linking? >>> >>> Can an absolute symbol be used instead? >> Here just some my thoughts about ABS symbol. It cause more symbol cost >> in the "*.o" files. For ABS symbols, if several "*.o" files are linked >> together, there will be several extra symbols. Llvm works OK by creating >> ABS symbol (I tried, but forgot the details), but GNU AS is not. Because >> it applies its ABS value to addend (, Qinggang has investigated before.). > Elf64_Sym is relatively smaller with just 24 bytes (unlike other > control structures in ELF). > To bypass a specific oddity in relocatable linking, consider using a > SHN_ABS symbol. > > You can define a SHN_ABS STB_GLOBAL STV_HIDDEN symbol to avoid > redundant copies within the link unit. > Duplicate SHN_ABS symbols of the same st_value do not cause duplicate > symbol definitions (except mold). > Alternatively, use STB_WEAK to make the deduplication intention clearer. A SHN_ABS STB_GLOBAL/STB_GLOBAL  STV_HIDDEN and non-zero symbol can be referenced by a relocation. A zero or local SHN_ABS symbol will directly add it's value to the addend of the relocation. rela_normal can prevent common code from handling MIPS relocations in a relocatable link. R_LARCH_ALIGN does not need to handle in a relocatable link. I prefer to use section symbol instead of adding an SHN_ABS symbol. > >>> On Fri, Mar 22, 2024 at 1:29 AM mengqinggang wrote: >>> I just saw this was pushed as commit daeda14191c1710ce967259a47ef4e0a3fb6eebf. >>> >>> The addition of the generic elf_backend_is_rela_normal flag seems like >>> something a global maintainer should take a closer look at. >>> In particular, I'm curious if Alan, the author of the "rela_normal" >>> commit (b491616acb5462a3694160ffef6413c160fed10a), has any thoughts on >>> this. >>> >>> The idea appears to be >>> (https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc#:~:text=R_LARCH_ALIGN) >>> >>> .text >>> break 1 >>> .p2align 4, , 8 // R_LARCH_ALIGN .text+0x0804 >>> break 8 >>> >>> In a relocatable link, the addend associated with the STT_SECTION >>> symbol is kept unchanged. >> Relocatable link merge input file text sections into one text section. >> If a relocation reference a section symbol, the addend would add the >> section offset in the final one text section. > This is exactly my concern. Using a STT_SECTION symbol requires a special case. > > https://inbox.sourceware.org/binutils/20020506132720.GT3698@bubble.sa.bigpond.net.au/ > specifies > >> mips is the fly in the ointment here, and the reason for elf_backend_rela_normal. > !rela_normal is weird, and we should not introduce more weird stuff > (R_LARCH_ALIGN referencing STT_SECTION).