From: Luis Machado <luis.machado@linaro.org>
To: Tom Tromey <tom@tromey.com>
Cc: Tom Tromey <tromey@adacore.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Find tailcall frames before inline frames
Date: Tue, 24 Mar 2020 18:24:03 -0300 [thread overview]
Message-ID: <cf5d7ef5-95e6-1976-6dbb-788b8cb948b2@linaro.org> (raw)
In-Reply-To: <9b864a68-3c28-9c25-6e3d-252777143e52@linaro.org>
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?
next prev parent reply other threads:[~2020-03-24 21:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-20 15:58 Tom Tromey
2020-03-03 21:45 ` Tom Tromey
2020-03-05 10:21 ` Luis Machado
2020-03-05 16:56 ` Tom Tromey
2020-03-09 17:55 ` Luis Machado
2020-03-12 21:34 ` Tom Tromey
2020-03-13 13:31 ` Luis Machado
2020-03-24 21:24 ` Luis Machado [this message]
2020-03-26 1:59 ` Tom Tromey
2020-03-26 2:47 ` Luis Machado
2020-06-18 18:25 ` Andrew Burgess
2020-06-18 21:07 ` Tom Tromey
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=cf5d7ef5-95e6-1976-6dbb-788b8cb948b2@linaro.org \
--to=luis.machado@linaro.org \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
--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