Date: Mon, 1 Nov 2021 11:39:05 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-stable List <stable@freebsd.org>, hackers@freebsd.org Subject: Re: gdb cannot cross doreti_ast ? Message-ID: <YX%2B1uV3NbzWKkVc1@kib.kiev.ua> In-Reply-To: <7064dc89-202e-36ea-02c5-a8872eac8eb4@FreeBSD.org> References: <7064dc89-202e-36ea-02c5-a8872eac8eb4@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 01, 2021 at 10:51:11AM +0200, Andriy Gapon wrote: > > I have a crash dump and kgdb (from gdb 10.2) cannot cross doreti_ast() when > examining a stack trace: > > #0 sched_switch (td=0xfffff801291507c0, newtd=0xfffff80061bc97c0, > flags=<optimized out>) at /usr/src/sys/kern/sched_ule.c:2146 > #1 0xffffffff80748494 in mi_switch (flags=266, newtd=0x0) at > /usr/src/sys/kern/kern_synch.c:452 > #2 0xffffffff80751154 in thread_suspend_switch (td=0xfffff801291507c0, > p=<optimized out>) at /usr/src/sys/kern/kern_thread.c:1118 > #3 0xffffffff80750f74 in thread_single (p=0xfffff8011df70000, > mode=<optimized out>) at /usr/src/sys/kern/kern_thread.c:862 > #4 0xffffffff80702b86 in exit1 (td=0xfffff801291507c0, rval=0, signo=15) at > /usr/src/sys/kern/kern_exit.c:240 > #5 0xffffffff80740f3a in sigexit (td=0xfffff801291507c0, sig=15) at > /usr/src/sys/kern/kern_sig.c:3194 > #6 0xffffffff8074230f in postsig (sig=15) at /usr/src/sys/kern/kern_sig.c:3079 > #7 0xffffffff80794b43 in ast (framep=0xfffffe0105a76c00) at > /usr/src/sys/kern/subr_trap.c:331 > #8 0xffffffff809b5449 in doreti_ast () at /usr/src/sys/amd64/amd64/exception.S:1150 > #9 0x00000008020c7400 in ?? () > #10 0x0000000000000011 in ?? () > #11 0x0000000000000000 in ?? () > > It's only a minor annoyance, but I would like to get it fixed. > Maybe some markers need to be added to doreti_ast? > Or some smarts need to be added to gdb to recognize doreti_ast? What do you want to see above doreti_ast? Basically there is no kernel frames, except the struct trapframe at the very top. doreti_ast is the last point with interrupts enabled (again) before return to usermode. The only wrong thing in this trace is that gdb did not stopped the unwinding. It might be that we could add some dwarf annotation to indicate the 'no frame' place.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YX%2B1uV3NbzWKkVc1>