From: Tom Tromey <tom@tromey.com>
To: Luis Machado <luis.machado@linaro.org>
Cc: Tom Tromey <tom@tromey.com>, Tom Tromey <tromey@adacore.com>,
gdb-patches@sourceware.org
Subject: Re: [PATCH] Find tailcall frames before inline frames
Date: Wed, 25 Mar 2020 19:59:51 -0600 [thread overview]
Message-ID: <87blojdgfc.fsf@tromey.com> (raw)
In-Reply-To: <cf5d7ef5-95e6-1976-6dbb-788b8cb948b2@linaro.org> (Luis Machado's message of "Tue, 24 Mar 2020 18:24:03 -0300")
>>>>> "Luis" == Luis Machado <luis.machado@linaro.org> writes:
Luis> Having spent a few days trying to understand this problem, it seems
Luis> all of these fi->level assertions (including
Luis> https://sourceware.org/bugzilla/show_bug.cgi?id=22748) are related to
Luis> attempting to unwind from places not safe to do so. That is, we're
Luis> trying to unwind some content (registers for example) before a given
Luis> frame is assigned a frame id.
Yes, I agree.
Luis> I think dwarf2_tailcall_sniffer_first would have to be called from
Luis> somewhere else, or conditions put in place. But I'm afraid adding more
Luis> conditions would complicate things further. And this code is already
Luis> reasonably complicated.
Luis> Since this is causing a number of inlining test failures for aarch64
Luis> and, from what i saw, some other architectures like s390, should we
Luis> consider reverting this while we discuss/review a reworked version of
Luis> the patch?
I think that would be fine. I haven't found the time to really dig into it.
I suspect that maybe the architectures doing this aren't playing by the rules.
Even so, though, it doesn't change that this used to work and now doesn't.
Tom
next prev parent reply other threads:[~2020-03-26 1:59 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
2020-03-26 1:59 ` Tom Tromey [this message]
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=87blojdgfc.fsf@tromey.com \
--to=tom@tromey.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