Re: port-i386/52560 (gdb kernel backtrace fails to show function where trap occurred)

[Maxime Villard <max%m00nbsd.net@localhost>]

The following reply was made to PR port-i386/52560; it has been noted by GNATS.

From: Maxime Villard <max%m00nbsd.net@localhost>
To: Andreas Gustafsson <gson%gson.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: port-i386/52560 (gdb kernel backtrace fails to show function
 where trap occurred)
Date: Sat, 24 Feb 2018 11:43:30 +0100

 Le 24/02/2018 à 10:18, Andreas Gustafsson a écrit :
 > maxv%NetBSD.org@localhost wrote:
 >> Can you re-test with the fix I committed?
 > 
 > I see that the change was reverted, but since I had already started a
 > test run of source date 2018.02.23.09.00.56, I might as well report
 > the results.  The change you committed did not fix the problem; the
 > function where the trap occurred was still not identified:
 > 
 > (gdb) bt
 > #0  maybe_dump (howto=260) at /usr/src/sys/arch/i386/i386/machdep.c:746
 > #1  0xc011c48d in cpu_reboot (howto=260, bootstr=0x0)
 >      at /usr/src/sys/arch/i386/i386/machdep.c:765
 > #2  0xc0c02a5a in vpanic (fmt=0xc10b0678 "trap",
 >      ap=0xceae8d78 "\020\216\256\316\020\216\256\316\002")
 >      at /usr/src/sys/kern/subr_prf.c:342
 > #3  0xc0c0288c in panic (fmt=0xc10b0678 "trap")
 >      at /usr/src/sys/kern/subr_prf.c:258
 > #4  0xc011fdd8 in trap (frame=0xceae8e10)
 >      at /usr/src/sys/arch/i386/i386/trap.c:323
 > #5  0xc0114492 in alltraps ()
 > #6  0xceae8e10 in ?? ()
 > #7  0xc0168313 in sy_call (sy=0xc16cda40 <sysent+4160>, l=0xc22cd540,
 >      uap=0xceae8f74, rval=0xceae8f6c) at /usr/src/sys/sys/syscallvar.h:65
 > #8  0xc01683e3 in sy_invoke (sy=0xc16cda40 <sysent+4160>, l=0xc22cd540,
 >      uap=0xceae8f74, rval=0xceae8f6c, code=208)
 >      at /usr/src/sys/sys/syscallvar.h:94
 > #9  0xc016868a in syscall (frame=0xceae8fa8)
 >      at /usr/src/sys/arch/x86/x86/syscall.c:140
 > #10 0xc01006a9 in Xsyscall ()
 > (gdb)
 > 
 > In the commit messsage, you wrote:
 >> Otherwise DDB is unable to display a correct stack trace
 >> if a fault occurred in a function before the frame was pushed.
 > 
 > DDB _is_ able to display a correct stack trace, or at least it was at
 > the time when the PR was filed, as shown at the beginning of the PR.
 > The problem only affects gdb.
 
 In fact your problem is that the _current_ function does not get displayed in
 GDB, and my patch fixed the fact that there were cases where you couldn't get
 the _previous_ function in DDB. I still put the PR in feedback, because I
 wanted to know whether somehow it would fix the issue you were getting.
 
 Maxime