58ffa42f64
Previously, the stack unwinder tried to locate the start of the function in each frame by walking backwards until it found an instruction that modified the stack pointer and then assumed that was the first instruction in a function. The unwinder would only print a function name if the starting instruction's address was an exact match for a symbol name. However, not all functions generated by modern compilers start off functions with that instruction. For those functions, the unwinder would fail to find a matching function name. As a result, most frames in a stack trace would be printed as raw hex PC's instead of a function name. Stop depending on this incorrect assumption and just use db_printsym() like other platforms to display the function name and offset for each frame. This generates a far more useful stack trace. While here, don't print out curproc's pid at the end of the trace. The pid was always from curproc even if tracing some other process. In addition, remove some rotted comments about hardcoded constants that are no longer hardcoded. Sponsored by: DARPA / AFRL |
||
---|---|---|
.. | ||
adm5120 | ||
alchemy | ||
atheros | ||
beri | ||
broadcom | ||
cavium | ||
conf | ||
gxemul | ||
idt | ||
include | ||
ingenic | ||
malta | ||
mediatek | ||
mips | ||
nlm | ||
rmi | ||
rt305x | ||
sibyte |