From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id 4C8D63858D20 for ; Fri, 11 Aug 2023 10:15:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4C8D63858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-1bbf8cb694aso15698045ad.3 for ; Fri, 11 Aug 2023 03:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691748939; x=1692353739; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=bpB2qB9pT+uKAD2cns8D/Bnte/AqIrA6ZTMyg8awvMM=; b=O1yR1PX+DvGh4cAEkMqZsAJ98+aDlWgx14yIwGxVoeSevuHNcH+zWCrkk/Ws68r+iH LSU1yuZzVG6twMOToTjHGFFR7IUkfc0DM4RXYwMIZksrFlO+FA0ox9ZBU0LLiIHM6Quq wRE/QhUK2/41z4p60Sk8y+oZpMZXQ6Npx02zInof5loAAgiqYn7swEmeusHmeSx1p7eu n/U2MaG0YGnsbv9slJihVnJuRbaIdLUPyFxtOqcEWorAYwnZUfkIqUK/HU36wwHLtcGr Ncy2c+WvkUmW2mdMQ9uCrNWjqqgkHMEGXax+VOIToTdbjcN01bYZR6eWyMsBf0k75np+ Dayg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691748939; x=1692353739; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bpB2qB9pT+uKAD2cns8D/Bnte/AqIrA6ZTMyg8awvMM=; b=HN+ySm8onHvCzw4AlLyvAYG/EoQVJuFZV6eXG37sgVTRJlSQM1HTk8R4igoix90+p3 8soSyeqpPgTWCBHr8CbtUpsstGIBvsnGpSw8cJsrZbcOCE+TMtX7SE4CN7lPivEJfMQ8 D5A8Etvu2Kv+HjiC82514IzNLouV/M6weYxfgwS/JKV7ctpmhnTDX+iZPu8z0cr4tlKV YLKpMy1qCvKBUFr3kgnj78P7pVUBsBQZai5aCdp4WC0g4YvAGdTHQoGC3u1GUpHhj4/P lCbKfiZGyyXYFGxtRpRTrhaxracELepgtAlFiKnTrzRSd0VBr9yDpVMPf+d3ZCzds6bS MOGQ== X-Gm-Message-State: AOJu0YxRlLhHvsXatiUDiYbKdrGcLOS026o1Scp+Xlcnyo74aPq6XSMj /qHH00h4f4OsuGHw7JQfI5NK2r8Kjw0= X-Google-Smtp-Source: AGHT+IFXWWoQTtClC2lwmkVPnutnUg8mWDa+VfTRM3hJffkLzl+xUUvSynysVbISzE7qDegnQrt76g== X-Received: by 2002:a17:903:4284:b0:1b8:adc:7c3d with SMTP id ju4-20020a170903428400b001b80adc7c3dmr1301614plb.40.1691748939016; Fri, 11 Aug 2023 03:15:39 -0700 (PDT) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:799c:d13:8ab2:6403]) by smtp.gmail.com with ESMTPSA id s18-20020a17090330d200b001bdbe6c86a9sm750186plc.225.2023.08.11.03.15.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Aug 2023 03:15:37 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 352C911404A3; Fri, 11 Aug 2023 19:45:35 +0930 (ACST) Date: Fri, 11 Aug 2023 19:45:35 +0930 From: Alan Modra To: Jan Beulich Cc: Jinyang He , mengqinggang , binutils@sourceware.org, Xing Li , Xi Ruoyao Subject: Re: [PATCH] Make sure DW_CFA_advance_loc4 is in the same frag Message-ID: References: <8771969c-b332-c008-3e35-c37c6c420c6e@loongson.cn> <17e42638-1b32-b7d5-7d85-3417b9375ba8@suse.com> <5941add1-23c9-46b2-3ff4-c14cf0cdcb9c@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5941add1-23c9-46b2-3ff4-c14cf0cdcb9c@suse.com> X-Spam-Status: No, score=-3026.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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 Fri, Aug 11, 2023 at 10:27:53AM +0200, Jan Beulich wrote: > On 11.08.2023 01:02, Alan Modra wrote: > > On Thu, Aug 10, 2023 at 02:55:20PM +0200, Jan Beulich wrote: > >> On 10.08.2023 14:36, Jinyang He wrote: > >>> 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. > >> > >> Well, Alan has approved your change. Maybe it's me who is wrong here. > > > > The idea behind commit b9d8f5601bcf was that when a > > DW_CFA_advance_loc4 of zero is seen in eh_frame_relax_frag and > > eh_frame_convert_frag we want to remove the opcode entirely, not just > > convert to a nop. If the opcode was split over two frags then the > > size adjustment would need to be done to the first frag, not the > > second as is correct for other cases with split frags. This would > > complicate the eh relaxation. It's easier to ensure the frag is not > > split. > > Oh, right, I can see that this makes things easier. But for the change > here, does frag_grow() actually help preventing the split? Yes. > Wouldn't it > need to be yet beyond what I suggested and require frag_more(5), No, because frag_more would move the obstack data pointer, and we want to leave that to the caller of check_eh_frame. > such > that intermediate section switches wouldn't close off the first frag? That shouldn't happen. check_eh_frame only does something when processing .eh_frame or .debug_frame sections. > Of course this would collide with what you say regarding size > adjustments needing to happen on the 2nd (variable) frag. (Aiui just > frag_grow() is enough in output_cfi_insn(), as there we aren't at risk > of intermediate section changes.) > > Jan -- Alan Modra Australia Development Lab, IBM