When a formal parameter 1 is not stored on stack the location list mark the
life of this parameter in DW_OP_reg0 however it does not consider the function
calls that would be made in the function in question and the fact that eax can
be destroyed down the call chain. Attached example demonstrates the problem.
gcc -m32 -O -g try.c
and here is .gdbinit file which would show the problem
file a.out
b 69
b 71
r
bt
c
bt
c
q
The sample looks like this
Breakpoint 1 at 0x80483b7: file try.c, line 69.
Breakpoint 2 at 0x80483bd: file try.c, line 71.
Breakpoint 1, __sfvwrite (fp=0xffffd810, uio=0x804a018) at try.c:69
69 {
#0 __sfvwrite (fp=0xffffd810, uio=0x804a018) at try.c:69
#1 0x080483e8 in __sprint (fp=0xffffd810, uio=0x804a018) at try.c:63
#2 0x0804840d in sprint (fp=0xffffd810, uio=0x804a018) at try.c:74
#3 0x08048436 in main () at try.c:81
Breakpoint 2, __sfvwrite (fp=0xffffd810, uio=0x804a018) at try.c:71
71 }
#0 __sfvwrite (fp=0xffffd810, uio=0x804a018) at try.c:71
#1 0x080483e8 in __sprint (fp=0x0, uio=0x804a018) at try.c:63 ------> fp is
wrong
#2 0x0804840d in sprint (fp=0xffffd810, uio=0x804a018) at try.c:74
#3 0x08048436 in main () at try.c:81
Program exited normally.
observe the value of frame 1 formal parameter 'fp' in backtrace.
--
Summary: stack trace shows wrong value for a formal parameter in
call-chain
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42638
