[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-gcc-list] Frame pointer location
From: |
Johannes Bauer |
Subject: |
[avr-gcc-list] Frame pointer location |
Date: |
Fri, 13 Aug 2010 10:32:42 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 |
Hello list,
I've got another question regarding the AVR ISR prologues: Let's say I
compile with -fno-omit-frame-pointer. Then the Y-ptr (r28:29) is used as
a FP. The resulting code for functions looks like this:
000087b4 <testfnc>:
87b4: af 92 push r10
87b6: bf 92 push r11
87b8: cf 92 push r12
87ba: df 92 push r13
87bc: ef 92 push r14
87be: ff 92 push r15
87c0: 0f 93 push r16
87c2: 1f 93 push r17
87c4: df 93 push r29
87c6: cf 93 push r28
87c8: cd b7 in r28, 0x3d ; 61
87ca: de b7 in r29, 0x3e ; 62
or, for an ISR
00008962 <__vector_96>:
8962: 1f 92 push r1
8964: 0f 92 push r0
8966: 0f b6 in r0, 0x3f ; 63
8968: 0f 92 push r0
896a: 08 b6 in r0, 0x38 ; 56
896c: 0f 92 push r0
896e: 18 be out 0x38, r1 ; 56
8970: 09 b6 in r0, 0x39 ; 57
8972: 0f 92 push r0
8974: 19 be out 0x39, r1 ; 57
8976: 0b b6 in r0, 0x3b ; 59
8978: 0f 92 push r0
897a: 1b be out 0x3b, r1 ; 59
897c: 11 24 eor r1, r1
897e: 0f 93 push r16
8980: 1f 93 push r17
8982: 2f 93 push r18
8984: 3f 93 push r19
8986: 4f 93 push r20
8988: 5f 93 push r21
898a: 6f 93 push r22
898c: 7f 93 push r23
898e: 8f 93 push r24
8990: 9f 93 push r25
8992: af 93 push r26
8994: bf 93 push r27
8996: ef 93 push r30
8998: ff 93 push r31
899a: df 93 push r29
899c: cf 93 push r28
899e: cd b7 in r28, 0x3d ; 61
89a0: de b7 in r29, 0x3e ; 62
i.e. the frame pointer is the *last* thing which changes during the
prologue. This makes sense since the amount of local variables reachable
via ldd/std "Y+n" operations is greater than when the frame pointer
would have been pushed as the first operation.
It has one major drawback, though: When trying to unwind the stack
manually, i.e., when I try to create a stacktrace, this is often not
possible, since I cannot rely on the return address being at Y+3/+4/+5.
The stack unwinding works, however, since Y+1/+2 always holds the last
frame pointer.
Is there an option to *always* make the frame pointer get pushed out
first? In an ISR that would have to happen even before SREG is pushed
onto the stack. It would make stacktraces possible.
If it is not possible and I would like to change that myself for
debugging - what parts would I have to look at? Is it easily done or is
that a difficult change?
Regards,
Johannes
- [avr-gcc-list] Frame pointer location,
Johannes Bauer <=