public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "ctice42 at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug backtrace/27987] New: aarch64 prologue unwinder does not correctly handle -fpatchable-function-entry=2 flag
Date: Wed, 16 Jun 2021 15:39:12 +0000	[thread overview]
Message-ID: <bug-27987-4717@http.sourceware.org/bugzilla/> (raw)

https://sourceware.org/bugzilla/show_bug.cgi?id=27987

            Bug ID: 27987
           Summary: aarch64 prologue unwinder does not correctly handle
                    -fpatchable-function-entry=2 flag
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: backtrace
          Assignee: unassigned at sourceware dot org
          Reporter: ctice42 at gmail dot com
  Target Milestone: ---

While debugging kgdb on a linux kernel built for aarch64 (inside chromiumos),
we found that if we built the kernel with -fpatchable-function-entry=2 and
tried to do a backtrace, the aarch64 prologue unwinder would not properly
handle/ignore the nops at the start of the function prologue, and would then
get confused about the stack, and would hit an assertion failure and crash gdb:

~/trunk/src/third_party/kernel/v5.4 $ aarch64-cros-linux-gnu-gdb         
vmlinux          -ex "target remote localhost:1234"
GNU gdb (Chromium OS 9.2.20200923 vanilla) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
…
Reading symbols from vmlinux...
Remote debugging using localhost:1234
arch_kgdb_breakpoint ()
    at
/home/cmtice/trunk/src/third_party/kernel/v5.4/./arch/arm64/include/asm/kgdb.h:21
21              asm ("brk %0" : : "I" (KGDB_COMPILED_DBG_BRK_IMM));
(gdb) bt
#0  arch_kgdb_breakpoint ()
    at
/home/cmtice/trunk/src/third_party/kernel/v5.4/./arch/arm64/include/asm/kgdb.h:21
#1  kgdb_breakpoint () at kernel/debug/debug_core.c:1208
/var/tmp/portage/cross-aarch64-cros-linux-gnu/gdb-9.2.20200923-r5/work/gdb-9.2/gdb/inline-frame.c:155:
internal-error: void inline_frame_this_id(struct frame_info *, void **, struct
frame_id *): Assertion `frame_id_p (*this_id)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y



If we build the kernel WITHOUT the -fpatchable-function-entry=2 flag and do the
same backtrace as the same location, we do get a corrupted stack error message,
but we don't hit the assert or the crash, we get a different (more correct)
backtrace, and because GDB doesn't actually crash, we can continue to do some
useful debugging:

~/trunk/src/third_party/kernel/v5.4 $ aarch64-cros-linux-gnu-gdb         
vmlinux          -ex "target remote localhost:1234"
GNU gdb (Chromium OS 9.2.20200923 vanilla) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
…
Reading symbols from vmlinux...
Remote debugging using localhost:1234
arch_kgdb_breakpoint ()
    at
/home/cmtice/trunk/src/third_party/kernel/v5.4/./arch/arm64/include/asm/kgdb.h:21
21              asm ("brk %0" : : "I" (KGDB_COMPILED_DBG_BRK_IMM));
(gdb) bt
#0  arch_kgdb_breakpoint ()
    at
/home/cmtice/trunk/src/third_party/kernel/v5.4/./arch/arm64/include/asm/kgdb.h:21
#1  kgdb_breakpoint () at kernel/debug/debug_core.c:1208
#2  0xffff8000131d0cd0 in kgdb_initial_breakpoint ()
    at kernel/debug/debug_core.c:1011
#3  dbg_late_init () at kernel/debug/debug_core.c:1026
#4  0xffff8000131b0bc4 in start_kernel () at init/main.c:1044
#5  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 


Sadly, the only test case I have been able to find is complex to reproduce, as
it
involves downloading and setting up a chromiumos chroot, then downloading,
configuring and building a copy of the linux kernel, then running the kernel in
qemu in the chromiumos chroot and running gdb in a separate terminal window. 
If someone really wants/needs the complete set of reproduction steps, let me
know and I will supply them.

I did debug this issue enough to verify that it is indeed the aarch64 prologue
unwinder that has the issue, but my knowledge of aarch64 is not good enough to
allow me to fix the issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

             reply	other threads:[~2021-06-16 15:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16 15:39 ctice42 at gmail dot com [this message]
2021-06-16 15:44 ` [Bug backtrace/27987] " ctice42 at gmail dot com
2021-06-25 13:01 ` luis.machado at linaro dot org
2021-06-26  6:28 ` ctice42 at gmail dot com
2021-06-28 17:52 ` luis.machado at linaro dot org
2021-06-29 14:00 ` luis.machado at linaro dot org
2021-06-29 14:34 ` luis.machado at linaro dot org
2021-06-29 17:07 ` luis.machado at linaro dot org
2021-06-29 17:08 ` luis.machado at linaro dot org

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=bug-27987-4717@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /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).