[PATCH] Find tailcall frames before inline frames

[Luis Machado]

Hi Tom,

On 3/13/20 10:31 AM, Luis Machado wrote:
> On 3/12/20 6:34 PM, Tom Tromey wrote:
>>>>>>> "Luis" == Luis Machado <luis.machado@linaro.org> writes:
>>
>> Luis> This has caused quite a few failures in the following tests for
>> Luis> aarch64-linux:
>>
>> I still haven't really tried to reproduce this yet.
>> I'll try tomorrow, I hope.
>>
>> Luis> ../../../repos/binutils-gdb/gdb/frame.c:579: internal-error: 
>> frame_id
>> Luis> get_frame_id(frame_info*): Assertion `fi->level == 0' failed.
>>
>> Meanwhile I wonder if this is the same as
>>
>> https://sourceware.org/pipermail/gdb-patches/2020-February/165511.html
>>
>> Tom
>>
> 
> The mention of fi->level looks the same, but i haven't looked into it yet.
> 
> I was planning to pinpoint the failure point in order to make this 
> easier to solve.

Having spent a few days trying to understand this problem, it seems all 
of these fi->level assertions (including 
https://sourceware.org/bugzilla/show_bug.cgi?id=22748) are related to 
attempting to unwind from places not safe to do so. That is, we're 
trying to unwind some content (registers for example) before a given 
frame is assigned a frame id.

For some cases we can see compute_frame_id being invoked in recursion 
for the same frame, which would lead to an infinite recursion. So the 
assertion catches this.

In my particular case, the call to dwarf2_tailcall_sniffer_first inside 
dwarf2_frame_cache leads to such infinite recursion, since no frame id 
has been assigned to the frame being used yet. It will be assigned by 
the time compute_frame_id is done.

I think dwarf2_tailcall_sniffer_first would have to be called from 
somewhere else, or conditions put in place. But I'm afraid adding more 
conditions would complicate things further. And this code is already 
reasonably complicated.

Since this is causing a number of inlining test failures for aarch64 
and, from what i saw, some other architectures like s390, should we 
consider reverting this while we discuss/review a reworked version of 
the patch?