Hello,
(Someone somewhere pointed this out to me, I'm sure others have noticed
it, but no one's done anything about this, sigh!)
One consequence of the frame rewrite was to modify the behavior of "info
frame". Previously it would print the location of registers saved by
_this_ frame:
Saved registers:
rbp at 0x7fbffff2e0, rip at 0x7fbffff2e8
but with the more agressive recursion it started printing out the
ultimate location of all the previous frame's registers,:
Saved registers:
rax at 0x7fbffff120, rbx at 0x7fbffff110, rcx at 0x7fbffff128, rdx at
0x7fbffff118, rsi at 0x7fbffff100, rdi at 0x7fbffff0f8, rbp at
0x7fbffff2e0, r8 at 0x7fbffff0b8, r9 at 0x7fbffff0c0, r10 at
0x7fbffff0c8, r11 at 0x7fbffff0d0, r12 at 0x7fbffff0d8, r13 at
0x7fbffff0e0, r14 at 0x7fbffff0e8, r15 at 0x7fbffff0f0, rip at
0x7fbffff2e8, eflags at 0x7fbffff140
Here all the extra saved registers come from a signal handler two levels
inner to the selected frame.
Further, as the stack evolved, the list of saved registers (and info
frame output) would change (different more inner frames saved registers
in different locations).
The attached checks that "info frame" doesn't change as the stack
evolves. Tested on fc3/amd64 it currently fails:
FAIL: gdb.base/savedregs.exp: Check main info frame; stack contains
catcher sigtramp thrower main
FAIL: gdb.base/savedregs.exp: Check main info frame; stack contains
caller dummy catcher sigtramp thrower main
FAIL: gdb.base/savedregs.exp: Check main info frame; stack contains
callee caller dummy catcher sigtramp thrower main
If the patch I'm about to post is applied, the test passes on fc3/amd64.