Binutils with MCST patches
259ba1e8ac
When encountering a return for which we have not seen a corresponding call, GDB starts a new back trace from level -1, i.e. from the level of the first function in the trace. In the presence of trace gaps, this may cause some rather big jump. (gdb) record function-call-history /c 192, +8 192 sbrk 193 brk 194 __x86.get_pc_thunk.bx 195 brk 196 __kernel_vsyscall 197 [disabled] 198 __kernel_vsyscall 199 brk 200 sbrk This doesn't help to make things more clear. Let's remain on the same level instead. (gdb) record function-call-history /c 192, +8 192 sbrk 193 brk 194 __x86.get_pc_thunk.bx 195 brk 196 __kernel_vsyscall 197 [disabled] 198 __kernel_vsyscall 199 brk 200 sbrk In this case it will look like we were able to connect the trace parts across the disabled gap. We were not. More work is required to achieve this. In the general case, the function-call history for the two trace parts won't match. They may be off by a few levels or they may be entirely different. All this patch does is to preserve the indentation level of the record function-call-history command. The disabled gap is caused by a sysenter not returning to the next instruction. (gdb) record function-call-history /i 196, +1 196 __kernel_vsyscall inst 66515,66519 (gdb) record instruction-history 66515 66515 0xb7fdcbf8 <__kernel_vsyscall+0>: push %ecx 66516 0xb7fdcbf9 <__kernel_vsyscall+1>: push %edx 66517 0xb7fdcbfa <__kernel_vsyscall+2>: push %ebp 66518 0xb7fdcbfb <__kernel_vsyscall+3>: mov %esp,%ebp 66519 0xb7fdcbfd <__kernel_vsyscall+5>: sysenter [disabled] 66520 0xb7fdcc08 <__kernel_vsyscall+16>: pop %ebp 66521 0xb7fdcc09 <__kernel_vsyscall+17>: pop %edx 66522 0xb7fdcc0a <__kernel_vsyscall+18>: pop %ecx 66523 0xb7fdcc0b <__kernel_vsyscall+19>: ret 66524 0xb7e8e09e <brk+30>: xchg %ecx,%ebx (gdb) disassemble 0xb7fdcbf8, 0xb7fdcc0c Dump of assembler code from 0xb7fdcbf8 to 0xb7fdcc0c: 0xb7fdcbf8 <__kernel_vsyscall+0>: push %ecx 0xb7fdcbf9 <__kernel_vsyscall+1>: push %edx 0xb7fdcbfa <__kernel_vsyscall+2>: push %ebp 0xb7fdcbfb <__kernel_vsyscall+3>: mov %esp,%ebp 0xb7fdcbfd <__kernel_vsyscall+5>: sysenter 0xb7fdcbff <__kernel_vsyscall+7>: nop 0xb7fdcc00 <__kernel_vsyscall+8>: nop 0xb7fdcc01 <__kernel_vsyscall+9>: nop 0xb7fdcc02 <__kernel_vsyscall+10>: nop 0xb7fdcc03 <__kernel_vsyscall+11>: nop 0xb7fdcc04 <__kernel_vsyscall+12>: nop 0xb7fdcc05 <__kernel_vsyscall+13>: nop 0xb7fdcc06 <__kernel_vsyscall+14>: int $0x80 0xb7fdcc08 <__kernel_vsyscall+16>: pop %ebp 0xb7fdcc09 <__kernel_vsyscall+17>: pop %edx 0xb7fdcc0a <__kernel_vsyscall+18>: pop %ecx 0xb7fdcc0b <__kernel_vsyscall+19>: ret End of assembler dump. I've seen this on 32-bit Fedora 23. I have not investigated what causes this and whether we can avoid the gap in the first place. Let's first try to make GDB handle such gaps more gracefully. gdb/ * btrace.c (ftrace_new_return): Start from the previous function's level if we can't find a matching call for a return. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING3 | ||
COPYING3.LIB | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
lt~obsolete.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
ylwrap |
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.