Failure to backtrace out of glibc system call stubs
Bug #684218 reported by
Yao Qi
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linaro GDB |
Fix Released
|
Medium
|
Ulrich Weigand | ||
eglibc (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
gdb (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
In linaro gdb r32980,
FAIL: gdb.base/
FAIL: gdb.base/
XPASS: gdb.base/
FAIL: gdb.base/
FAIL: gdb.base/
FAIL: gdb.base/
FAIL: gdb.base/
=== gdb Summary ===
# of expected passes 13
# of unexpected failures 6
# of unexpected successes 1
We can see the same failures in GDB cvs trunk.
Related branches
tags: | added: testsuite |
Changed in gdb-linaro: | |
assignee: | nobody → Ulrich Weigand (uweigand) |
Changed in gdb-linaro: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
This failure goes away if debug information for glibc is present.
The problem is that without CFI debug data, GDB is currently unable to backtrace out of the "kill" routine correctly:
000259f0 <kill>: start_main+ 0x1d0>
259f0: e1a0c007 mov ip, r7
259f4: e3a07025 mov r7, #37 ; 0x25
259f8: ef000000 svc 0x00000000
259fc: e1a0700c mov r7, ip
25a00: e3700a01 cmn r0, #4096 ; 0x1000
25a04: 312fff1e bxcc lr
25a08: eaffbf0c b 15640 <__libc_
25a0c: e320f000 nop {0}
because it doesn't detect that r7 has been saved into ip. (Thus, when backtracing out of the caller requires use of the caller's r7, GDB uses the incorrect value.)
Unfortunately, even with my patch to add support for ARM unwind tables (#661253), this particular case *still* is not handled, because the kill routine doesn't even provide correct ARM unwind tables. See the discussion leading up to this: sourceware. org/ml/ gdb-patches/ 2010-12/ msg00005. html
http://
So it looks like a glibc fix will be required in addition to the #661253 GDB fix.