From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id F2A713858C78 for ; Tue, 1 Mar 2022 10:33:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F2A713858C78 Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-73-NVGQsycPPiSqDkCvgA9BDA-1; Tue, 01 Mar 2022 05:33:56 -0500 X-MC-Unique: NVGQsycPPiSqDkCvgA9BDA-1 Received: by mail-wm1-f70.google.com with SMTP id 187-20020a1c19c4000000b0037cc0d56524so801228wmz.2 for ; Tue, 01 Mar 2022 02:33:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=1CSuGuxtD96/m1D13dab616u+AmP501uQ+sNlE/JlSA=; b=6pytjJxZrj5FVdjoSrq5LR1nPCk9wPnGO9papWbAnLcerix4RhoV6rBOlmEHGT/SAt 0AU7HpZUpOLSwfAUfniBOsWaxD8pkngDwth1XsIlW2ennf+XTi1+b37emtUG0Df/D3Vw 5I4XEoyIiEfDvG0+TuTO7BDWinqQ/g2VNhVhv/qS2MlEb6ve0IzxybNZ0SJzXw6fyk3j 7St0ZC/sUoVEBibDq33raXp8nfuHq00oD90l0TdTcde3wIA+e5erbSx1nd2QEJZA+JNR hEdQ42ZjrRvI7dMBmO/IoP27fpMPRvqjU0vaCxz/oh+wUwNrV9gR72PyQG2QKjecIGHV 5mgg== X-Gm-Message-State: AOAM532SLFiv8L/+ew3FYfl2xJjYhmluQz7I8c5fmNusb0KxcdPgcCl3 Mb4RcTG1ufOkd+eE+DDPgDNcVB/kgmOyz7BNE/HMAFdkgvxp0qwyi0cDBFUdw+NjXHnmSbxOI89 Vs9XRDpN29YcOrd6QyxB1Eg== X-Received: by 2002:a1c:2644:0:b0:381:10f:503 with SMTP id m65-20020a1c2644000000b00381010f0503mr16429856wmm.188.1646130835068; Tue, 01 Mar 2022 02:33:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJyKjaJifw3nNOiZ1YtG9xZJaEizvOyjE4ypQ5jDB/YRkhxXtdbslUVJBYf6lyYhhpEoCyv6mA== X-Received: by 2002:a1c:2644:0:b0:381:10f:503 with SMTP id m65-20020a1c2644000000b00381010f0503mr16429837wmm.188.1646130834730; Tue, 01 Mar 2022 02:33:54 -0800 (PST) Received: from localhost (host86-169-131-29.range86-169.btcentralplus.com. [86.169.131.29]) by smtp.gmail.com with ESMTPSA id v12-20020a5d4a4c000000b001e68ba61747sm13254142wrs.16.2022.03.01.02.33.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Mar 2022 02:33:54 -0800 (PST) From: Andrew Burgess To: Lifang Xia , gdb-patches@sourceware.org Cc: Lifang Xia Subject: Re: [PATCH] [RISC-V]: Handling optimized prologue In-Reply-To: <20220301073231.1927-1-lifang_xia@c-sky.com> References: <20220301073231.1927-1-lifang_xia@c-sky.com> Date: Tue, 01 Mar 2022 10:33:53 +0000 Message-ID: <87h78iynam.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2022 10:34:00 -0000 Lifang Xia writes: Hello Lifang, Thanks for working on this. > From: Lifang Xia > > The optimizer might shove anything into the prologue, if > we build up cache (cache != NULL) from scanning prologue, > we just skip what we don't recognize and scan further to > make cache as complete as possible. My concern here would be, what if the thing you are skipping over modifies the state in such a way, that when we think we are building the cache, we're really doing the wrong thing in some way... > However, if we skip > prologue, we'll stop immediately on unrecognized > instruction. > > The case is: > > ---------------------------- > Disassembly of section .text: > > 0000000000010078 : > 10078: 00100513 li a0,1 > 1007c: 008000ef jal ra,10084 > 10080: 00008067 ret > > 0000000000010084 : > 10084: 00051263 bnez a0,10088 > 10088: ff010113 addi sp,sp,-16 > 1008c: 00813023 sd s0,0(sp) > 10090: 00050413 mv s0,a0 > 10094: 00113423 sd ra,8(sp) > 10098: 014000ef jal ra,100ac > 1009c: 00813083 ld ra,8(sp) > 100a0: 00013403 ld s0,0(sp) > 100a4: 01010113 addi sp,sp,16 > 100a8: 00008067 ret > > 00000000000100ac : > 100ac: 00000013 nop >>> 100b0: 00008067 ret > ---------------------- > (gdb) bt > #0 0x00000000000100b0 in aaa () > #1 0x000000000001009c in bar () > Backtrace stopped: frame did not save the PC I assume it's the bnez that's causing the problem for the prologue scan here? Not that I really understand what that instruction is about, it appears to be branching to the next instruction. I wonder if this objdump output is for the object file, rather than the executable? I'm guessing the bnez has a reloc which points at, maybe, the ret at 0x100a8? I wonder if a better solution in this case would be to allow the prologue scan to skip over forward branches within the prologue, maybe with the limitation that the destination has to be within the function bounds? > > gdb/ > * riscv-tdep.c (riscv_scan_prologue): Keep scaning if cache is not NULL. > --- > gdb/riscv-tdep.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c > index 886996c..e46d441 100644 > --- a/gdb/riscv-tdep.c > +++ b/gdb/riscv-tdep.c > @@ -1987,7 +1987,15 @@ riscv_scan_prologue (struct gdbarch *gdbarch, > else > { > end_prologue_addr = cur_pc; > - break; > + > + /* The optimizer might shove anything into the prologue, if > + we build up cache (cache != NULL) from scanning prologue, > + we just skip what we don't recognize and scan further to > + make cache as complete as possible. However, if we skip > + prologue, we'll stop immediately on unrecognized > + instruction. */ > + if (cache == NULL) Use nullptr not NULL please. Thanks, Andrew > + break; > } > } > > -- > 2.7.4