This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug backtrace/16771] New: AVR: Backtraces fail for functions with no locals and -fno-omit-frame-pointer
- From: "justin at jgottula dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Sat, 29 Mar 2014 05:07:28 +0000
- Subject: [Bug backtrace/16771] New: AVR: Backtraces fail for functions with no locals and -fno-omit-frame-pointer
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16771
Bug ID: 16771
Summary: AVR: Backtraces fail for functions with no locals and
-fno-omit-frame-pointer
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: backtrace
Assignee: unassigned at sourceware dot org
Reporter: justin at jgottula dot com
Stack unwinding consistently fails to work properly when an AVR program (for
atxmega128a3) is compiled with -fno-omit-frame-pointer:
(gdb) bt
#0 0x00000bae in can_spi_xfer (byte=128 '\200') at src/io/stdfile.c:55
#1 0x0000000c in __vectors ()
Frame #0 is correct, #1 is garbage, and nothing else is shown even though this
is several calls deep.
When compiled with -fno-omit-frame-pointer, typical function prologues with NO
local variables look like this:
000019b0 <main>:
19b0: cf 93 push r28
19b2: df 93 push r29
19b4: cd b7 in r28, 0x3d ; 61
19b6: de b7 in r29, 0x3e ; 62
or this:
00001436 <fifo_init.1460>:
1436: 0f 93 push r16
1438: 1f 93 push r17
143a: cf 93 push r28
143c: df 93 push r29
143e: cd b7 in r28, 0x3d ; 61
1440: de b7 in r29, 0x3e ; 62
The documentation for the avr_scan_prologue function in gdb/avr-tdep.c says:
A typical AVR function prologue with a frame pointer might look like this:
push rXX ; saved regs
...
push r28
push r29
in r28,__SP_L__
in r29,__SP_H__
sbiw r28,<LOCALS_SIZE>
in __tmp_reg__,__SREG__
cli
out __SP_H__,r29
out __SREG__,__tmp_reg__
out __SP_L__,r28
And, correspondingly, scan_stage 2 of avr_scan_prologue does indeed require
that the frame pointer subtraction and stack pointer transfer are present,
meaning that the two examples above fail to be processed correctly and aren't
To fix this problem, scan_stage 2 of avr_scan_prologue needs to be less
restrictive, such that function prologues that use the frame pointer, yet don't
have local variables, will be successfully scanned as AVR_PROLOGUE_NORMAL.
--
You are receiving this mail because:
You are on the CC list for the bug.