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

[Andreas Gustafsson <gson%gson.org@localhost>]

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

From: Andreas Gustafsson <gson%gson.org@localhost>
To: maxv%NetBSD.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:18:39 +0200

 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.
 -- 
 Andreas Gustafsson, gson%gson.org@localhost