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 206D5385B51F for ; Thu, 10 Aug 2023 12:36:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 206D5385B51F 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 [111.9.175.10]) by gateway (Coremail) with SMTP id _____8Bxd+jo2dRk9qoUAA--.8548S3; Thu, 10 Aug 2023 20:36:57 +0800 (CST) Received: from [10.136.12.26] (unknown [111.9.175.10]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Dx5szj2dRkHyJTAA--.55872S3; Thu, 10 Aug 2023 20:36:52 +0800 (CST) Subject: Re: [PATCH] Make sure DW_CFA_advance_loc4 is in the same frag To: Jan Beulich References: Cc: Jinyang He , Alan Modra , mengqinggang , binutils@sourceware.org, Xing Li , Xi Ruoyao From: Jinyang He Message-ID: <8771969c-b332-c008-3e35-c37c6c420c6e@loongson.cn> Date: Thu, 10 Aug 2023 20:36:51 +0800 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-CM-TRANSID:AQAAf8Dx5szj2dRkHyJTAA--.55872S3 X-CM-SenderInfo: pkhmx0p1dqwqxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBj93XoW7CF4DZw1kWFyDurW3KF4rWFX_yoW8Kw1kpr W5GFWDKF4DJ3s7Ar92kF4xWrs5uw13GF43trZ5t3yYyFWDXr1Iqr1xCryaqa4xurZYk3yY 9a10qrs8Ar9xA3gCm3ZEXasCq-sJn29KB7ZKAUJUUUUr529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUBFb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r106r15M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2kKe7AKxVWUXVWUAwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07 AIYIkI8VC2zVCFFI0UMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWU XVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI4 8JMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_ Jr0_Gr1l4IxYO2xFxVAFwI0_Jrv_JF1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8Gjc xK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0 cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8V AvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E 14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07je0PfUUUUU= X-Spam-Status: No, score=-7.6 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: On /Thu Aug 10 07:55:58 GMT 2023 /Jan Beulich wrote: > On 10.08.2023 04:21, Jinyang He wrote: > >/The DW_CFA_advance_loc4 may be in different frags. Then fr_fix />/may caused something wrong. Referenced by commit b9d8f5601bcf />/("Re: Optimise away eh_frame advance_loc 0"). / > I'm afraid I don't understand that earlier fix: frag_more(1) there > ought to guarantee fr_fix (once the frag is closed) to be >= 1. > It would then seem to me that ... I'm not familiar with it. Please point out my mistakes. Thanks in advance. DW_CFA_advance_loc4 requires 1 byte, and follows contents requires no more than 4 bytes. In state_saw_loc4-case, it can be optimized to DW_CFA_advance_{loc, loc1, loc2, loc4}. Current the two processes are asynchronous. It means that the state_wait_loc4-case exit check_eh_frame() firstly and then enter state_saw_loc4-case when reenter check_eh_frame(). Thus, we actually need these 5 bytes to be in the same frags and the loc4_fix point the first char. > > >/--- a/gas/ehopt.c />/+++ b/gas/ehopt.c />/@@ -386,7 +386,7 @@ check_eh_frame (expressionS *exp, unsigned int > *pnbytes) />/{ />//* This might be a DW_CFA_advance_loc4. Record the frag and the />/position within the frag, so that we can change it later. */ />/- frag_grow (1); />/+ frag_grow (1 + 4); />/d->state = state_saw_loc4; />/d->loc4_frag = frag_now; />/d->loc4_fix = frag_now_fix (); / > ... here instead we also need > > frag_more (1); Either frag_more or frag_grow does not actually change frag_now if frchain_now has enough rooms (rooms >= nchar). Compare to frag_grow, frag_more has return values and empty space to zeros. Both frag_more or frag_grow, they should check 5 bytes. Thus, simply call "frag_grow(5)" here to ensure that both parts of DW_CFA_advance_* are in the same frags. > d->state = state_saw_loc4; > d->loc4_frag = frag_now; > d->loc4_fix = frag_now_fix () - 1; > > Otoh if frags were always grown (there and here), couldn't we do away > with loc4_frag and loc4_fix? > > As to your 2.41 question: You realize the release was already cut? > Putting this (or whichever else) fix there would be likely be okay, but > would have a real effect only if 2.41.1 was ever made. I know it's been released. I just wish it was available in [1]. [1] https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/binutils-2_41-branch Jinyang