Page MenuHomeFreeBSD

[mips] [ddb] few backtrace changes
Needs ReviewPublic

Authored by on Jan 22 2018, 10:32 PM.




  • added userland support: read info from virtual memory of process
  • replace hardcoded registers by macros
  • added address of subroutine to easy lookup in binary file

Commented code will be removed before commit...

Test Plan

Tested for a long time under mipsel broadcom hardware. It saves me a lot of time ;)

Example of new output:

db> bt
Tracing pid 215 tid 100061 td 0x80862b40
[kernel]        kdb_enter+0x48 (?,?,?,?) ra 8018e6e4 sp c0473b90 sz 24 subr 8018e594
[kernel]        kdb_sysctl_enter+0xbc (?,?,?,?) ra 8014f7b0 sp c0473ba8 sz 48 subr 8018e628
[kernel]        sysctl_root_handler_locked+0xa4 (?,?,?,?) ra 8014fa78 sp c0473bd8 sz 56 subr 8014f70c
[kernel]        sysctl_root+0xd8 (?,?,?,?) ra 8014fed4 sp c0473c10 sz 96 subr 8014f9a0
[kernel]        userland_sysctl+0x110 (80862b40,?,?,?) ra 80150184 sp c0473c70 sz 112 subr 8014fdc4
[kernel]        sys___sysctl+0xac (?,?,?,?) ra 80349874 sp c0473ce0 sz 168 subr 801500d8
[kernel]        trap+0x1000 (?,?,?,?) ra 80336304 sp c0473d88 sz 248 subr 80348874
[kernel]        MipsUserGenException+0x10c (?,?,?,?) ra 00000000 sp c0473e80 sz 0 subr 803361f8
--- exception, cause 406ef300 badvaddr 0 ---
[/tmp/test_tls] (0 400000 4cb000) 0x86e24       0x486e24 (?,?,?,?) ra 004862fc sp 7bffde40 sz 0 subr 486e18
[/tmp/test_tls] (0 400000 4cb000) 0x862fc       0x4862fc (?,?,?,?) ra 00483794 sp 7bffde40 sz 64 subr 48628c
[/tmp/test_tls] (0 400000 4cb000) 0x83794       0x483794 (?,?,?,?) ra 00482f38 sp 7bffde80 sz 160 subr 48371c
[/tmp/test_tls] (0 400000 4cb000) 0x82f38       0x482f38 (?,?,?,?) ra 0047cc64 sp 7bffdf20 sz 72 subr 482edc
[/tmp/test_tls] (0 400000 4cb000) 0x7cc64       0x47cc64 (?,?,?,?) ra 00400598 sp 7bffdf68 sz 40 subr 47cbdc
[/tmp/test_tls] (0 400000 4cb000) 0x598 0x400598 (?,?,?,?) ra 00403198 sp 7bffdf90 sz 32 subr 40054c
[/tmp/test_tls] (0 400000 4cb000) 0x3198 0x403198 (?,?,?,?) ra 00000000 sp 7bffdfb0 sz 56 subr 402ecc

Diff Detail

rS FreeBSD src repository
Lint Skipped
Unit Tests Skipped

Event Timeline edited the test plan for this revision. (Show Details)Jan 22 2018, 10:32 PM
brooks added a reviewer: jhb.Jan 23 2018, 10:05 PM
brooks added subscribers: jhb, brooks.

Add @jhb who is a ddb expert and is working on mips debugging.

jhb added inline comments.Jan 23 2018, 11:37 PM

What instruction is this? Looks to be 'addu, gp, gp,t9' which is used not at the start of a PIC function, but a few instructions in after loading a constant offset into gp? The existing MIPS_START_OF_FUNCTION seems to usually be the next instruction in the routines I'm looking at in libc, and since the loop walks backwards from the given PC, it would seem to hit that condition first and not use this one? Was there a function you encountered that didn't do the stack adjustment but only the GP setup? (This is also O32-specific it seems. For N64 the instruction should be daddu and it seems the stack adjustment is in fact the first instruction for N64 and the GP setup is afterwards.)


You can't assume curproc here. You can do stack traces on non-curproc. Probably you need to check if the requested thread thread belongs to curproc. You could have the callers of stacktrace_subr() do this and setting a bool arg passed to stacktrace_subr to permit userspace tracing only for threads belonging to curproc.


None of this code is safe to do in a debugger. You might have panic'd in the filesystem code in which case you might deadlock on one of these locks, etc. In general debugger commands aren't permitted to take locks, etc. None of the other stack tracers in DDB on other architectures attempt to list filenames for lines. You can still get that via kgdb or a similar debugger when examining a core or via remote debugging.


These casts aren't needed (if anything we should remove them from the other places already using uintmax_t casts).

@jhb, many thanks for review!

Initial code of userland stacktracing was written to fix TLS on MIPS few months ago. I found it useful.
May be it should be ddb command different from "bt", for instance "bt\u".


Yes, it's. There is no need to find exact start of function. We need approximate location to further analysis where old values of registers are stored.
And yes, it's MIPS O32. I'll add daddu for N64. How to test mips64? qemu?


Ough... my mistake. Pointer to thread is to be passed to stacktrace_subr. I'll fix it.


The file name brings ability to identify particular routine and manually to restore stack trace. I tried kgdb via remote debugging on soho routers, so seems it's required additional UART.
I see way to avoid VM_OBJECT locks, but don't see how to avoid it with vm_map_lookup and vn_fullpath. I'll appreciate any advice about them with note that file name is enough (full path is nice to have).


Thanks. It's not intended, may be result of git-rebase.