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 AA4233858426 for ; Sat, 7 Oct 2023 01:23:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AA4233858426 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 loongson.cn (unknown [10.20.4.171]) by gateway (Coremail) with SMTP id _____8AxlPD5siBljawvAA--.26224S3; Sat, 07 Oct 2023 09:23:06 +0800 (CST) Received: from [10.20.4.171] (unknown [10.20.4.171]) by localhost.localdomain (Coremail) with SMTP id AQAAf8CxbS_4siBlzsgZAA--.54772S3; Sat, 07 Oct 2023 09:23:04 +0800 (CST) Subject: Re: [PATCH 1/2] LoongArch: bfd: Remove elf_seg_map condition in loongarch_elf_relax_section To: Xi Ruoyao , Jinyang He , Chenghua Xu , Zhensong Liu , WANG Xuerui Cc: binutils@sourceware.org, Xing Li , yala , Peng Fan References: <20230711084931.18978-1-hejinyang@loongson.cn> <679cafe2-f5fb-dc76-61db-f5ecb6fd1776@loongson.cn> <98e6ae12-404d-010a-4640-b116b4c6899b@loongson.cn> <2b547680-2a07-b3bd-933a-955910981bc2@loongson.cn> <16094953d52e88d269591129ed9aed3efa6ae761.camel@xry111.site> <3316ceeff68fd7e8ca7a9fe1d1e5c58c94d1dad2.camel@xry111.site> From: mengqinggang Message-ID: Date: Sat, 7 Oct 2023 09:23:04 +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: <3316ceeff68fd7e8ca7a9fe1d1e5c58c94d1dad2.camel@xry111.site> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8CxbS_4siBlzsgZAA--.54772S3 X-CM-SenderInfo: 5phqw15lqjwttqj6z05rqj20fqof0/ X-Coremail-Antispam: 1Uk129KBj93XoW7Kr1kWw4kCFy8tr4fWrWkKrX_yoW8Gw4Dpa yUGw4IyFs7G3s5Gwn7ta1xA3Wakws5W343Jr1agr1DW3s8AFyktFsFyw45ua4kCwsxCw1Y qr42qa1kWr98ZagCm3ZEXasCq-sJn29KB7ZKAUJUUUUr529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUBjb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_ Gr0_Gr1UM2kKe7AKxVWUXVWUAwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYI kI8VC2zVCFFI0UMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUXVWU AwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMx k0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_ Gr1l4IxYO2xFxVAFwI0_Jrv_JF1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67 AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8I cVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI 8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v2 6r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jjwZcUUUUU= X-Spam-Status: No, score=-7.7 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: Hi, I will send a patch in the next few days to solve this issue and other issues related to relaxation. 在 2023/10/5 下午7:19, Xi Ruoyao 写道: > On Thu, 2023-10-05 at 18:09 +0800, Xi Ruoyao via Binutils wrote: >> Hi Jinyang, >> >> Any progress on this?  During my attempt trying to balance relaxation >> and scheduling better in GCC I found the elf_seg_map condition is >> preventing relaxation on *every* shared library (when we are linking a >> shared library the elf_seg_map of .text is NULL). >> >> On a modern system most code paths are in shared libraries, so it's >> really bad not to perform the relaxation on them.  Esp. now we are >> disabling explicit relocs for relaxation, so if we don't relax shared >> libraries we are likely regressing the overall performance of the >> system. > Phew. It's not only a performance issue. It's actually a *correctness* > issue because the condition also causes R_LARCH_ALIGN skipped, so some > programs depending on code alignment (for e.g. duff-device-like code > using pcaddi for eg) will be broken. > > Generally skipping the entire relaxation pass for any section containing > R_LARCH_ALIGN is wrong (as we've discussed in > https://github.com/llvm/llvm-project/pull/67424). Even if we don't > really relax a thing we still *must* process R_LARCH_ALIGN. > >> Sorry for disturbing you during the national holiday, feel free to defer >> the reply until the holiday ends!