This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Bug in Dwarf2 .debug_frame section [RE: Gcc 3.0 and ARM Stackframe]


Ok, I'm continuing to debug this even if i'm alone...

Now i can generate the .debug_frame by a gross hack. The thing now is that
the information is incorrect (at least the Arm debugger can't make any sense
of it). 

I used the fromELF from ARM, to output the debug information genrated by gnu
in human readable format (you an can also use gcc with -S -dA to generate a
commented assembly source.)

Here is the commented assembly source of prologue of a function (fun1)

fun1:
.LFB1:
.LM1:
        @ args = 0, pretend = 0, frame = 4
        @ frame_needed = 1, current_function_anonymous_args = 0
        mov     ip, sp
.LCFI0:
        stmfd   sp!, {fp, ip, lr, pc}
.LCFI1:
        sub     fp, ip, #4
.LCFI2:
        sub     sp, sp, #4
.LCFI3:
        str     r0, [fp, #-16]

The frame info generated by gcc for those line is: 

  CIE 000000: version 1, "", code align 000001, data align fffffffc, return
reg r14
    DW_CFA_def_cfa r13=0
  FDE 000010: CIE 000000, init loc 000000, range 000054
    DW_CFA_advance_loc +0x4 = 0x000004
    DW_CFA_def_cfa_register r12
    DW_CFA_advance_loc +0x4 = 0x000008
    DW_CFA_offset r14=0xfffffff8
    DW_CFA_offset r13=0xfffffff4
    DW_CFA_offset r11=0xfffffff0
    DW_CFA_advance_loc4 +0x4 =0x00000c
    DW_CFA_def_cfa r11=0xfffffff0
    DW_CFA_nop 
    DW_CFA_nop 


In clear that means that: 

. At the beggining (pc=0) the frame address (cfa) is  [r13] (DW_CFA_def_cfa
r13=0), r13=sp
. After the second instructionis executed (pc>4) the cfa is [r12]
(DW_CFA_def_cfa_register r12), this is a result of the instruction "mov ip,
sp" (ip=r12)
. After that three register (r11,r13,r14) are saved on the stack (stmfd
sp!, {fp, ip, lr, pc}) (r11 =fp, lr=r14, pc=r15)
. Then after the next instruction "sub fp, ip, #4" we should have the new
cfa = [r11 + 4] since the instruction means r11 = r12 - 4. Now the debug
information reported is DW_CFA_def_cfa r11=0xfffffff0 which means the new
cfa is [r11 - 16]

Actually if you look at the way it is coded at the lowest level the offset
shown here is calculated by (value coded) * (data align factor). You can see
in the first line the data align factor is fffffffc (= -4) so when the debug
info has been coded by gcc it had forgotten the "data align factor" in this
case.

In fact the "data align factor"  is the value of the
DWARF_CIE_DATA_ALIGNMENT macro. Unfortunately this macro is only used in one
case (thats in dwarf2out.c line 761). All the upper level function use the
offset in bytes, but when the offset is passed to the add_fde_cfi function
is should be mesured in unit of DWARF_CIE_DATA_ALIGNEMENT. Or so i guess. 

I found  4 occurences where add_fde_cfi is used. Only when apparently use
DWARF_CIE_DATA_ALIGNEMENT before to adjsut the offset value.

So i guess there is a bug somewhere but i'm not sure what fix should be
applied. And i'm surely overlooking some things.

Does somebody has any insight about it? Who is maintening the dwarf2 stuff?

Thanks

	Fabrice



> -----Original Message-----
> From: Fabrice Gautier 
> Sent: Wednesday, September 26, 2001 9:30 PM
> To: Fabrice Gautier; 'gcc@gcc.gnu.org'
> Subject: RE: Gcc 3.0 and ARM Stackframe
> 
> 
> 
> Well, I've tried gcc 3.01 and it doesn't output .debug_frame 
> section neither.
> 
> I've looked a bit in the code and it seems that all the code 
> is already there to output this section. I've hacked gcc to 
> see if it was indeed calling this code, and it is. So i don't 
> understand really why there's no .debug_frame section in my 
> final image (arm-elf target, -g and even -gdwarf-2 at compile time).
> 
> I've traced gcc all the way down to 
> dwarf2out_frame_debug_expr which is called 11 times in my 
> smallish test program.
> 
> I'm thinking that maybe everything is computed but the 
> section is not written in the file at the end of the 
> compilation.But I can't find where this happen. Can somebody help me
> 
> Thanks
> 
> >  -----Original Message-----
> > From: 	Fabrice Gautier  
> > Sent:	Tuesday, September 25, 2001 10:45 AM
> > To:	'gcc@gcc.gnu.org'
> > Subject:	Gcc 3.0 and ARM Stackframe
> > 
> > Hi,
> > 
> > When compiling with gcc 2.95 for ARM, it's not possible to 
> > have the ARM debugger display the call stack (or backtrace as 
> > they say) I saw a message about the problem, syaing it was 
> > because gcc was not generating proper stack frame. (However 
> > gdb seems to display the call stack, go figure...)
> > 
> > As there is a new ARM backend in Gcc 3.0, I would like to 
> > know if this new backend generate proper stack frame for the 
> > ARM debugger ?
> > 
> > Thank you,
> > 
> > -- 
> > Fabrice Gautier
> > Software Engineer, Sigma Designs
> > Fabrice_Gautier@sdesigns.com
> > 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]