Re: [PATCH] Fix inline frame unwinding breakage

[Luis Machado <luis.machado@linaro.org>]

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 <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
> 

I'll take a look at it.