public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Luis Machado <luis.machado@linaro.org>
To: Tom de Vries <tdevries@suse.de>, gdb-patches@sourceware.org
Cc: tromey@adacore.com, andrew.burgess@embecosm.com
Subject: Re: [PATCH] Fix remaining inline/tailcall unwinding breakage for x86_64
Date: Mon, 27 Apr 2020 09:07:16 -0300	[thread overview]
Message-ID: <b08d4a9b-de14-375f-391b-814b70dcead8@linaro.org> (raw)
In-Reply-To: <c852d2dc-b18c-08c6-3327-89141f1ea4fe@suse.de>

On 4/25/20 12:53 PM, Tom de Vries wrote:
> On 25-04-2020 06:09, Luis Machado wrote:
>> Commit 5939967b355ba6a940887d19847b7893a4506067 fixed inline
>> frame unwinding breakage for some targets (aarch64, riscv, s390...)
>> but regressed a few amd64 testcases related to tailcalls.
>>
>> Given the following example situation...
>>
>> Frame #-1 - sentinel frame
>> Frame # 0 - inline frame
>> Frame # 1 - normal frame
>>
>> ... suppose we're at level #1 and call into dwarf2_tailcall_sniffer_first.
>>
>> We'll attempt to fetch PC, which used to be done via the gdbarch_unwind_pc call
>> (before 5939967b355ba6a940887d19847b7893a4506067), but now it is being handled
>> by the get_frame_register function.
>>
>> gdbarch_unwind_pc will attempt to use frame #1's cache to retrieve information
>> about the PC. Here's where different architectures behave differently.
>>
>> x86_64 will find a dwarf rule to retrieve PC from memory, at a CFA + offset
>> location. So the PC value is readily available and there is no need to
>> create a lazy value.
>>
>> For aarch64 (and others), GCC doesn't emit an explicit location for PC, so we
>> eventually will find that PC is DWARF2_FRAME_REG_UNSPECIFIED. This is known
>> and is handled by GDB by assuming GCC really meant DWARF2_FRAME_REG_SAME_VALUE.
>>
>> This means we'll attempt to fetch the register value from frame #0, via a call
>> to frame_unwind_got_register, which will trigger the creation of a lazy value
>> that requires a valid frame id for frame #0.
>>
>> We don't have a valid id for frame #0 yet, so we assert.
>>
>> Given the above, the following patch attempts to handle the situation without
>> being too hacky. We verify if the next frame is an inline frame and if its
>> frame id has been computed already. If it hasn't been computed yet, then we
>> use the safer get_frame_register function, otherwise we use the regular
>> gdbarch_unwind_pc hook.
>>
>> I've verified this makes both aarch64-linux and x86_64 happy testsuite-wise.
>>
> 
> Hi Luis,
> 
> thanks for working on this.
> 
> I've tested this patch on x86_64-linux and can confirm that this fixes
> all the regressions I saw.
> 
> I've reviewed the patch and it looks ok to me.
> 
> Please check this in, given that if fixes regressions.  If there are any
> comments from others to be addressed, that can still be done post-commit.
> 
> Thanks,
> - Tom
> 

Thanks for the quick review. Pushed now.

      reply	other threads:[~2020-04-27 12:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-25  4:09 Luis Machado
2020-04-25 15:53 ` Tom de Vries
2020-04-27 12:07   ` Luis Machado [this message]

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=b08d4a9b-de14-375f-391b-814b70dcead8@linaro.org \
    --to=luis.machado@linaro.org \
    --cc=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tdevries@suse.de \
    --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).