From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf42.google.com (mail-qv1-xf42.google.com [IPv6:2607:f8b0:4864:20::f42]) by sourceware.org (Postfix) with ESMTPS id 2B51938930D5 for ; Fri, 24 Apr 2020 10:58:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2B51938930D5 Received: by mail-qv1-xf42.google.com with SMTP id q31so4404938qvf.11 for ; Fri, 24 Apr 2020 03:58:36 -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:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nQAIcFipvO2y2kDYGaKDtu6kq82TJ6B8O94hUohjlAc=; b=BWiv6WPC03mJnMchwYFc8Lg2HWxQtjAq7CUs3xs7v6BcH6QuF3R/jwb+XBt2JoI7d6 UV1HAXRQVxo8ywYCXgLx9UkBLv2BYs+VtFyx/s05Q7R4GuCMdoDtpw2BWyrz5hON+JeC nJCY137+fvJgvsWIKY/TGnTbt08CqDYRHYz2NaTrtxfF1yi/F7diixbeU2wjdXE1QH+7 8fQfS5T3F3g/0tfpw9xUCZsoIGnC1xMBpqMTGws5Rhv4LjOorX7mv5eb9FZBfH7sgfku S/H8d9zVDUkDW+XjokS77l0N9VkbXYbCe9YdDTCMqS3NNz1tV0DKeOoxSpKlOoV9/J3o ivSA== X-Gm-Message-State: AGi0PuYwYrF3h5r3OaZLdp/tEX7rGhzTOwLsbxLcCxBPxH1NGUXXhIeS ROAFgsuD83lgC26YlNt8FLKHVxnvsqA= X-Google-Smtp-Source: APiQypJwGf9kKnQtgaUPvq3sHChabn6rflVGWzBbPOYHM6OKf6YE5vy/B1+O+o0YasSX8xyiq3QtVg== X-Received: by 2002:a0c:e88d:: with SMTP id b13mr8463555qvo.245.1587725915169; Fri, 24 Apr 2020 03:58:35 -0700 (PDT) Received: from [192.168.0.185] ([191.251.166.36]) by smtp.gmail.com with ESMTPSA id c69sm3325021qkg.104.2020.04.24.03.58.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Apr 2020 03:58:34 -0700 (PDT) Subject: Re: [PATCH] Fix inline frame unwinding breakage From: Luis Machado 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> Message-ID: Date: Fri, 24 Apr 2020 07:58:31 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.6 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 10:58:37 -0000 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?