From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) by sourceware.org (Postfix) with ESMTPS id 98F313893651 for ; Fri, 24 Apr 2020 11:37:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 98F313893651 Received: by mail-qk1-x744.google.com with SMTP id n143so9764562qkn.8 for ; Fri, 24 Apr 2020 04:37:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HvGrvT9dYtDzkX0Lg2bGBizoDL0IhpPJjqbWiJqhnpU=; b=SZLIH6HRroe/2Il7loTgBdyxmM9hAMhUEA6XG+k0STwiF//9MNjRwfGhvjmsCEc3Y1 H9zDFccUkRWlnt27/Jcxg9Gqixa1y+5lpQxTSgrW5HhWm0KfECpLO5rg8WJGg8zrpXJN n1tYVLulbtrBKSjvwx/kthcCCQRS1Vo1se8Gwy80GPF7ImJNeZY4xqG46h6XhI7I9q+7 2kdly1wesGt1oP4m6S0de3ZHVizfUS9lrM6VvC3YA63S6ZItBjyZpjChu79VIgUALorn xyURmckq3FQoU5+ZlViuuBEcXYymrrozZCsJ106PtmNd+Xd8BkydXCOFI357RpnxnxTU kdvQ== X-Gm-Message-State: AGi0Puai4hQDpMBKsuAARcER5U6FEemakSi1oSMGag5FPuNq69oB8sZ+ lgPrkRwPeB4cX72NPoV1HIFK4xWIqEc= X-Google-Smtp-Source: APiQypJ3f2VoMSnaALVtO3yS/SCgJTGDEV8tExgeawC3Af++kvsHY+jDuxMHQjqiTfCl2+u4zvwVYQ== X-Received: by 2002:a05:620a:cd7:: with SMTP id b23mr8474473qkj.22.1587728227720; Fri, 24 Apr 2020 04:37:07 -0700 (PDT) Received: from [192.168.0.185] ([191.251.166.36]) by smtp.gmail.com with ESMTPSA id b126sm3376140qkc.119.2020.04.24.04.37.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Apr 2020 04:37:06 -0700 (PDT) Subject: Re: [PATCH] Fix inline frame unwinding breakage To: Tom de Vries , Andrew Burgess Cc: tromey@adacore.com, gdb-patches@sourceware.org References: <20200414213137.24015-1-luis.machado@linaro.org> <20200414213836.24370-1-luis.machado@linaro.org> <20200422093723.GA3522@embecosm.com> <9722a14e-83af-03c6-b120-aac9816f9fc9@linaro.org> <12f56c2f-5d1f-9f98-e91a-762e76018966@suse.de> <20452d56-2189-1b67-6df0-ea26c7402a91@suse.de> From: Luis Machado Message-ID: <7c23ff9b-50c5-e697-c3ef-bda7db251ab2@linaro.org> Date: Fri, 24 Apr 2020 08:37:04 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20452d56-2189-1b67-6df0-ea26c7402a91@suse.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Fri, 24 Apr 2020 11:37:15 -0000 On 4/24/20 8:08 AM, Tom de Vries wrote: > On 24-04-2020 12:58, Luis Machado wrote: >> On 4/24/20 7:02 AM, Luis Machado wrote: >>> On 4/24/20 6:17 AM, Tom de Vries wrote: >>>> On 23-04-2020 19:51, Luis Machado via Gdb-patches wrote: >>>>> On 4/22/20 8:22 AM, Luis Machado wrote: >>>>>> Hi Andrew, >>>>>> >>>>>> On 4/22/20 6:37 AM, Andrew Burgess wrote: >>>>>>> * Luis Machado via Gdb-patches >>>>>>> [2020-04-14 18:38:36 -0300]: >>>>>>> >>>>>>>> *** re-sending due to the poor choice of characters for the >>>>>>>> backtrace >>>>>>>> annotations. GIT swallowed parts of it. >>>>>>>> >>>>>>>> There has been some breakage for aarch64-linux, arm-linux and >>>>>>>> s390-linux in >>>>>>>> terms of inline frame unwinding. There may be other targets, but >>>>>>>> these are >>>>>>>> the ones i'm aware of. >>>>>>>> >>>>>>>> The following testcases started to show numerous failures and >>>>>>>> trigger internal >>>>>>>> errors in GDB after commit 1009d92fc621bc4d017029b90a5bfab16e17fde5, >>>>>>>> "Find tailcall frames before inline frames". >>>>>>>> >>>>>>>> gdb.opt/inline-break.exp >>>>>>>> gdb.opt/inline-cmds.exp >>>>>>>> gdb.python/py-frame-inline.exp >>>>>>>> gdb.reverse/insn-reverse.exp >>>>>>>> >>>>>>>> The internal errors were of this kind: >>>>>>>> >>>>>>>> binutils-gdb/gdb/frame.c:579: internal-error: frame_id >>>>>>>> get_frame_id(frame_info*): Assertion `fi->level == 0' failed. >>>>>>> >>>>>>> I have also started seeing this assert on RISC-V, and your patch >>>>>>> resolves this issue for me, so I'm keen to see this merged. >>>>>> >>>>>> Great. >>>>>> >>>>>>> >>>>>>> I took a look through and it all looks good to me - is there anything >>>>>>> holding this back from being merged? >>>>>> >>>>>> Not really. I was waiting for an OK before pushing it. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Andrew >>>>> >>>>> I've pushed this now. Tromey and Andrew OK-ed it on IRC. >>>> >>>> This causes at least: >>>> ... >>>> FAIL: gdb.arch/amd64-entry-value.exp: tailcall: bt >>>> FAIL: gdb.arch/amd64-entry-value.exp: tailcall: p i >>>> FAIL: gdb.arch/amd64-entry-value.exp: tailcall: p i@entry >>>> FAIL: gdb.arch/amd64-entry-value.exp: tailcall: p j >>>> FAIL: gdb.arch/amd64-entry-value.exp: tailcall: p j@entry >>>> FAIL: gdb.arch/amd64-entry-value.exp: p $sp0 == $sp >>>> FAIL: gdb.arch/amd64-entry-value.exp: frame 3 >>>> FAIL: gdb.arch/amd64-entry-value.exp: down >>>> FAIL: gdb.arch/amd64-entry-value.exp: disassemble >>>> FAIL: gdb.arch/amd64-entry-value.exp: ambiguous: bt >>>> FAIL: gdb.arch/amd64-entry-value.exp: self: bt >>>> FAIL: gdb.arch/amd64-entry-value.exp: self: bt debug entry-values >>>> FAIL: gdb.arch/amd64-tailcall-cxx.exp: bt >>>> FAIL: gdb.arch/amd64-tailcall-noret.exp: bt >>>> FAIL: gdb.arch/amd64-tailcall-self.exp: bt >>>> ... >>>> >>>> Looking at the first FAIL, before this commit we have: >>>> ... >>>> (gdb) PASS: gdb.arch/amd64-entry-value.exp: continue to breakpoint: >>>> tailcall: breakhere >>>> bt^M >>>> #0  d (i=71, i@entry=70, j=73.5, j@entry=72.5) at >>>> gdb.arch/amd64-entry-value.cc:34^M >>>> #1  0x00000000004006af in c (i=i@entry=7, j=j@entry=7.25) at >>>> gdb.arch/amd64-entry-value.cc:47^M >>>> #2  0x00000000004006cd in b (i=i@entry=5, j=j@entry=5.25) at >>>> gdb.arch/amd64-entry-value.cc:59^M >>>> #3  0x0000000000400524 in main () at gdb.arch/amd64-entry-value.cc:229^M >>>> (gdb) PASS: gdb.arch/amd64-entry-value.exp: tailcall: bt >>>> ... >>>> which has now degraded into: >>>> ... >>>> (gdb) PASS: gdb.arch/amd64-entry-value.exp: continue to breakpoint: >>>> tailcall: breakhere >>>> bt^M >>>> #0  d (i=, j=) at >>>> gdb.arch/amd64-entry-value.cc:34^M >>>> #1  0x0000000000400524 in main () at gdb.arch/amd64-entry-value.cc:229^M >>>> (gdb) FAIL: gdb.arch/amd64-entry-value.exp: tailcall: bt >>>> ... >>>> >>>> Thanks, >>>> - Tom >>>> >>> >>> I'll take a look at it. >> >> Just a quick update... I did a before/after run and the only regression >> seems to be from gdb.arch/amd64-entry-value.exp. >> >> The other failures are still there even after reverting the inline frame >> unwinding fix. >> >> I'll check what's up with the regressed test. >> >> Could you please confirm this when you have some cycles? > > Hi, > > I cannot confirm this. All these FAILs fail with the patch, and pass > with the patch reverted. > > Looking at amd64-tailcall-cxx.exp, we have normally: > ... > (gdb) bt^M > #0 g (x=x@entry=2) at gdb.arch/amd64-tailcall-cxx1.cc:23^M > #1 0x00000000004004e8 in f (x=x@entry=1) at > gdb.arch/amd64-tailcall-cxx2.cc:23^M > #2 0x00000000004003de in main () at gdb.arch/amd64-tailcall-cxx1.cc:31^M > (gdb) PASS: gdb.arch/amd64-tailcall-cxx.exp: bt > ... > and with the patch: > ... > (gdb) bt^M > #0 g (x=2) at gdb.arch/amd64-tailcall-cxx1.cc:23^M > #1 0x00000000004003de in main () at gdb.arch/amd64-tailcall-cxx1.cc:31^M > (gdb) FAIL: gdb.arch/amd64-tailcall-cxx.exp: bt > ... > > So, I'd say it looks very similar to the issue in > gdb.arch/amd64-entry-value.exp. > > Thanks, > - Tom > Ok. I double-checked this and I'm still seeing failures for those that i mentioned, even with the patch reverted. It may be the case that these tests are not supposed to pass (or the testcase has issues) on non-amd64 targets (running Intel here). I'll work with the testcase that does show the issue. Hopefully a fix for that will address all the others, but i may need further confirmation. Thanks, Luis