Bug 17994 - avr-gcc does not output a dwarf2 .debug_frame section
avr-gcc does not output a dwarf2 .debug_frame section
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: target
3.4.1
: P2 enhancement
: 4.7.0
Assigned To: Not yet assigned to anyone
:
Depends on: 19885 47597
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-14 08:22 UTC by Torleif Sandnes
Modified: 2011-08-02 20:49 UTC (History)
7 users (show)

See Also:
Host: 386
Target: avr-*-*
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-08-20 22:40:26


Attachments
Initial fix that emits the output shown in comment 5 (2.20 KB, patch)
2011-02-16 08:20 UTC, Anitha Boyapati
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Torleif Sandnes 2004-10-14 08:22:21 UTC
avr-gcc-v:
Reading specs from c:/programs/WinAVR/bin/../lib/gcc/avr/3.4.1/specs
Configured with: ../gcc-3.4.1/configure --prefix=e:/avrdev/install
--build=mingw32 --host=mingw32 --target=avr --enable-languages=c,c++
Thread model: single
gcc version 3.4.1

command line:
avr-gcc -gdwarf-2 anycode.c  -o anyobject.elf

No matter how I tweak the command line parameters to avr-gcc I am unable to make
it output dwarf2 callstack information (.debug_frame). I have confirmed that
this is a missing feature for the AVR port.
Comment 1 Björn Haase 2005-05-06 13:59:27 UTC
Hi, 
 
I have been reviewing PR19885 and come to the following conclusions: 
 
1.) As expected, Torleif is right: I can confirm that the problem exists,  
2.) it should, however, probably be called rather a request for enhancement 
than a bug: Beside call stack information the debugging info should be ok in 
principle. 
3.) There seems to be only one little part missing in order to add the call 
stack information as well: The back-end needs to provide the information at 
which memory address the debugger could localize the return address. This would 
require to implement the target hook INCOMING_RETURN_ADDR_RTX and use the 
RTX_FRAME_RELATED_P predicate for all of the prologue/epilogue insn. 
 
I think the best way to address this issue would be to resolve this issue 
simultaneously when switching from asm-prologue/epilogue to 
RTL-prologue/epilogue. Since Andy Hutchinson is just working on this issue, we 
might soon have a solution. Hopefully :-). Would be very helpfull to have call 
stack info in avrstudio. 
 
Yours, 
 
Bjoern 
 
P.S.:  
I hope you will not be flaming me for adding you on the CC list. :-) Just 
thought that you might be interrested since I know you are working on the 
prologue/epilogue issue. 
Comment 2 Eric Weddington 2009-08-20 22:40:25 UTC
Hi Torleif,

Please check more recent versions such as 4.3.2, 4.3.3, or 4.4.0. There are .debug_frame sections in there, but I don't know if it contains the information that you're looking for.

Thanks,
Eric Weddington
Comment 3 Torleif Sandnes 2009-10-23 11:41:29 UTC
I tried gcc 4.3.2 from the WinAVR distribution and also avr-gcc 4.4.1.

The short story is: There is call frame information there, but not enough. Specifically, the Call Frame instructions to reconstruct the pc to unwind rule table are still missing, but the CIE and FDE are present. 

I compared gcc and avr-gcc output on linux with the following results:

gcc:
-----------------------------------------------------------------------
The section .debug_frame contains:

00000000 00000010 ffffffff CIE
  Version:               1
  Augmentation:          ""
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 8

  DW_CFA_def_cfa: r4 (esp) ofs 4
  DW_CFA_offset: r8 (eip) at cfa-4
  DW_CFA_nop
  DW_CFA_nop

00000014 00000024 00000000 FDE cie=00000000 pc=08048394..0804840a
  DW_CFA_advance_loc: 4 to 08048398
  DW_CFA_def_cfa: r1 (ecx) ofs 0
  DW_CFA_register: r4 (esp) in r1 (ecx)
  DW_CFA_advance_loc: 6 to 0804839e
  DW_CFA_def_cfa: r4 (esp) ofs 4
  DW_CFA_advance_loc: 1 to 0804839f
  DW_CFA_def_cfa_offset: 8
  DW_CFA_offset: r5 (ebp) at cfa-8
  DW_CFA_advance_loc: 2 to 080483a1
  DW_CFA_def_cfa_register: r5 (ebp)
  DW_CFA_advance_loc: 1 to 080483a2
  DW_CFA_offset: r4 (esp) at cfa-12
  DW_CFA_nop
  DW_CFA_nop

0000003c 00000014 00000000 FDE cie=00000000 pc=0804840a..0804841c
  DW_CFA_advance_loc: 1 to 0804840b
  DW_CFA_def_cfa_offset: 8
  DW_CFA_offset: r5 (ebp) at cfa-8
  DW_CFA_advance_loc: 2 to 0804840d
  DW_CFA_def_cfa_register: r5 (ebp)

-----------------------------------------------------------------------

avr-gcc 

-----------------------------------------------------------------------
00000000 0000000c ffffffff CIE
  Version:               1
  Augmentation:          ""
  Code alignment factor: 1
  Data alignment factor: -1
  Return address column: 36

  DW_CFA_def_cfa: r32 ofs 0

00000010 0000000c 00000000 FDE cie=00000000 pc=000000ce..00000160

00000020 0000000c 00000000 FDE cie=00000000 pc=00000160..0000018c

-----------------------------------------------------------------------
Comment 4 Anitha Boyapati 2010-12-29 07:05:09 UTC
(In reply to comment #1)
 
> 3.) There seems to be only one little part missing in order to add the call 
> stack information as well: The back-end needs to provide the information at 
> which memory address the debugger could localize the return address. This would 
> require to implement the target hook INCOMING_RETURN_ADDR_RTX and use the 
> RTX_FRAME_RELATED_P predicate for all of the prologue/epilogue insn. 


I know this has been delayed for too long. But I thought a small update would perhaps help.

Looks like to get call-stack debug info, all we require to do is define INCOMING_RETURN_ADDR_RTX. In AVR, since the return address is pushed onto the stack for every call instruction, the above hook is defined to avr_incoming_return_addr_rtx() of dwarf2out.c:

rtx
avr_incoming_return_addr_rtx(void) {

    return gen_rtx_MEM (HImode, stack_pointer_rtx);
}

And this gives an ICE in dwarf2out_frame_debug_expr(). Modifying the above function to pre decrement the stack pointer gives an ICE in initial_return_save()

gen_rtx_MEM (HImode, gen_rtx_PRE_DEC (HImode, stack_pointer_rtx))
Comment 5 Anitha Boyapati 2010-12-29 07:08:33 UTC
(In reply to comment #4)

> 
> And this gives an ICE in dwarf2out_frame_debug_expr(). Modifying the above
> function to pre decrement the stack pointer gives an ICE in
> initial_return_save()
> 
> gen_rtx_MEM (HImode, gen_rtx_PRE_DEC (HImode, stack_pointer_rtx))

gcc version - 4.4.3
Comment 6 Anitha Boyapati 2010-12-29 13:35:34 UTC
(In reply to comment #4)

> Looks like to get call-stack debug info, all we require to do is define
> INCOMING_RETURN_ADDR_RTX. In AVR, since the return address is pushed onto the
> stack for every call instruction, the above hook is defined to
> avr_incoming_return_addr_rtx() of dwarf2out.c:
> 
> rtx
> avr_incoming_return_addr_rtx(void) {
> 
>     return gen_rtx_MEM (HImode, stack_pointer_rtx);
> }
> 
> And this gives an ICE in dwarf2out_frame_debug_expr(). Modifying the above
> function to pre decrement the stack pointer gives an ICE in
> initial_return_save()
> 

The reason for ICE is that POST_DEC is not handled in dwarf2out_frame_debug_expr(). Fixing that issue will enable the compiler to generate the call-stack debug info.

http://gcc.gnu.org/ml/gcc/2010-12/msg00474.html

#simple testcase:
void foo(){ return ;}
int main() { foo(); return 1; }


The output of .debug_frame section for the above testcase(just assembled):

00000000 00000010 ffffffff CIE
  Version:               1
  Augmentation:          ""
  Code alignment factor: 1
  Data alignment factor: -1
  Return address column: 36

  DW_CFA_def_cfa: r32 ofs 2
  DW_CFA_offset: r36 at cfa+0
  DW_CFA_nop
  DW_CFA_nop

00000014 00000014 00000000 FDE cie=00000000 pc=00000000..0000000e
  DW_CFA_advance_loc: 4 to 00000004
  DW_CFA_offset: r28 at cfa+0
  DW_CFA_advance_loc: 4 to 00000008
  DW_CFA_def_cfa_register: r28
  DW_CFA_nop
  DW_CFA_nop

0000002c 00000014 00000000 FDE cie=00000000 pc=0000000e..00000022
  DW_CFA_advance_loc: 4 to 00000012
  DW_CFA_offset: r28 at cfa+0
  DW_CFA_advance_loc: 4 to 00000016
  DW_CFA_def_cfa_register: r28
  DW_CFA_nop
  DW_CFA_nop

Comments on correctness appreciated :)
Comment 7 Richard Henderson 2011-02-15 19:36:28 UTC
(In reply to comment #6)
> The reason for ICE is that POST_DEC is not handled in
> dwarf2out_frame_debug_expr(). Fixing that issue will enable the compiler to
> generate the call-stack debug info.

This is handled by properly defining INCOMING_FRAME_SP_OFFSET.
You don't need a POST_DEC in the INCOMING_RETURN_ADDR_RTX definition.

C.f. the i386 versions of these, which set up the exact same sort of
on-stack return address.
Comment 8 Anitha Boyapati 2011-02-16 08:20:03 UTC
Created attachment 23360 [details]
Initial fix that emits the output shown in comment 5

(In reply to comment #7)
> (In reply to comment #6)
> > The reason for ICE is that POST_DEC is not handled in
> > dwarf2out_frame_debug_expr(). Fixing that issue will enable the compiler to
> > generate the call-stack debug info.
> This is handled by properly defining INCOMING_FRAME_SP_OFFSET.
> You don't need a POST_DEC in the INCOMING_RETURN_ADDR_RTX definition.
> C.f. the i386 versions of these, which set up the exact same sort of
> on-stack return address.


Going by the internals document, INCOMING_FRAME_SP_OFFSET is already defined but it is not used anywhere (in my patch).

Looking at i386, I understand that the return address is stored on the stack much in the same way. However, what I dont understand is the requirement for cfa initialization in prologue expansion. This is something not handled in AVR. 

> You don't need a POST_DEC in the INCOMING_RETURN_ADDR_RTX definition.

INCOMING_RETURN_ADDR_RTX per se is not using POST_DEC. But once they are defined to some values, during the libgcc build, an ICE is hit in dwarf2out_frame_debug_expr(). If POST_DEC mode is defined, ICE disappears. I am yet to understand the relation between the POST_DEC and ICE and why it appears when only CFI is being emitted.


Attaching the patch.
Comment 9 Richard Henderson 2011-02-16 18:04:08 UTC
> Going by the internals document, INCOMING_FRAME_SP_OFFSET is already defined
> but it is not used anywhere (in my patch).

Certainly it's going to be used by the generic code in dwarf2out_frame_init,
and if that's wrong everything that follows will be off as well.

> INCOMING_RETURN_ADDR_RTX per se is not using POST_DEC. But once they are
> defined to some values, during the libgcc build, an ICE is hit in
> dwarf2out_frame_debug_expr(). If POST_DEC mode is defined, ICE disappears. I am
> yet to understand the relation between the POST_DEC and ICE and why it appears
> when only CFI is being emitted.

Ah, I see.  Nothing to do with the initial frame setup, but the rest of the
unwind info, since AVR uses POST_DEC for pushes.

See 

  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01059.html

for my proposed patch for this.  Note that the message contains both gas
and gcc patches.
Comment 10 Torleif.Sandnes 2011-08-02 20:46:09 UTC
I am on vacation, but will be back 8th August.

Torleif Sandnes
Comment 11 Richard Henderson 2011-08-02 20:49:40 UTC
Fixed for 4.7.  Will not be backported to earlier branches.