public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: Luis Machado <luis.machado@linaro.org>,
	Andrew Burgess <andrew.burgess@embecosm.com>
Cc: tromey@adacore.com, gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix inline frame unwinding breakage
Date: Fri, 24 Apr 2020 11:17:25 +0200	[thread overview]
Message-ID: <12f56c2f-5d1f-9f98-e91a-762e76018966@suse.de> (raw)
In-Reply-To: <9722a14e-83af-03c6-b120-aac9816f9fc9@linaro.org>

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 <gdb-patches@sourceware.org>
>>> [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=<optimized out>, j=<optimized out>) 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

  reply	other threads:[~2020-04-24  9:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14 21:31 Luis Machado
2020-04-14 21:38 ` Luis Machado
2020-04-16 21:15   ` Tom Tromey
2020-04-22  9:37   ` Andrew Burgess
2020-04-22 11:22     ` Luis Machado
2020-04-23 17:51       ` Luis Machado
2020-04-24  9:17         ` Tom de Vries [this message]
2020-04-24 10:02           ` Luis Machado
2020-04-24 10:58             ` Luis Machado
2020-04-24 11:08               ` Tom de Vries
2020-04-24 11:37                 ` Luis Machado
2020-04-24 12:23                   ` Tom de Vries
2020-04-24 13:19                     ` Luis Machado
2020-04-24 14:36                       ` Tom de Vries
2020-04-24 14:39                         ` Luis Machado
2020-06-18 16:58   ` Andrew Burgess
2020-06-18 17:29     ` Andrew Burgess
2020-06-18 17:40       ` Andrew Burgess
2020-06-18 18:19         ` Luis Machado
2020-06-18 18:31           ` Andrew Burgess
2020-06-18 18:39             ` Luis Machado
2020-06-22 15:49               ` Andrew Burgess
2020-06-18 17:45       ` Luis Machado
2020-06-18 18:04         ` Andrew Burgess

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12f56c2f-5d1f-9f98-e91a-762e76018966@suse.de \
    --to=tdevries@suse.de \
    --cc=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=luis.machado@linaro.org \
    --cc=tromey@adacore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).