Custom call frame description

Custom call frame description

[Mitar]

Hi!

I am writing a simple compiler for a custom/learning language on the
ARM platform. It is written in Java and outputs assembler code which
is then assembled with GNU assembler. As sometimes things do not work
as planned I would like to be able to use gdb to debug them,
especially stack, but as I have a custom call frame format gdb is
unable to unwind/read a stack trace. I have tried to get through DWARF
specification but I could not really manage how to specify frame
format in a simple way. I have checked GCC's source code but I got
lost in DWARF versions. DWARF Tutorial was useful but had no examples
for call frame. So I am a bit lost how to proceed. What should I write
to a assembler file so that resulting object file would have a call
frame description? My compiler does not optimise anything and
everything (return addresses and arguments -  they are always passed
over the stack) are all nicely stored in the stack. So by reading
stack I could easily debug output of my compiler.

So I would ask for advice and/or some example of an assembler code for
DWARF call frame description. My frame looks like this (all values are
32 bit):

static link (frame pointer points here and where is return value
stored after current function call)
local variables (some number of them)
old frame pointer
return address
temporary variables (where I store registers when there is not enough of them)
function arguments for next call


Mitar

Re: Custom call frame description

[Tom Tromey]

>>>>> "Mitar" == Mitar  <mmitar@gmail.com> writes:

Mitar> So I would ask for advice and/or some example of an assembler code for
Mitar> DWARF call frame description. My frame looks like this (all values are
Mitar> 32 bit):

One thing you can do is run gcc -S on simple programs and look at the
resulting assembly.  Adding -dA can help clarify things, too.

Tom

Re: Custom call frame description

[Mitar]

Hi!

On Fri, Jan 22, 2010 at 5:42 PM, Tom Tromey <tromey@redhat.com> wrote:
> One thing you can do is run gcc -S on simple programs and look at the
> resulting assembly.  Adding -dA can help clarify things, too.

Oh, thanks. I was looking at -S but it was cryptic without -dA. And I
have some success now.

But I am not sure to what I have to set canonical frame address? To
top address of the call frame or to the bottom? Because otherwise I
use top of the frame (where fp register is pointing) in my compiler
from which I calculate access to different elements of the frame.
While my sp is pointing at the bottom of the frame and I do not really
use it (except in the next function call). Somehow I got a feeling
that I should follow sp with canonical frame address but this is
somehow strange as I am using fp for my frame access. Also I
incrementally lower sp in my function prelude - should I change
canonical frame address for every instruction then? Or should I
immediately offset it for complete frame size?

Stack level 0, frame at 0xbef66c34: << should this point to top or
bottom of the frame?
 pc = 0x876c in _insert (prg.s:74); saved pc 0x8a48
 called by frame at 0xbef66c84 << same here, should this be top or
bottom of the frame?
 source language asm.
 Arglist at 0xbef66c34, args:
 Locals at 0xbef66c34, Previous frame's sp is 0xbef66c34 << this is
not really in sync with called frame address?

Currently I set CFA to sp register in initial commands and then when
in prolog, when I store current sp to fp, I switch CFA to fp register.
But at that moment things break and I get:

Stack level 0, frame at 0xbef66c34:
 pc = 0x8774 in _insert (prg.s:77); saved pc 0x8a48
 called by frame at 0xbef66c34
 source language asm.
 Arglist at 0xbef66c34, args:
 Locals at 0xbef66c34, Previous frame's sp is 0xbef66c34

My prolog looks like:

_insert:
    str fp, [sp, #-8]
    mov fp, sp
.L_insert_fp_defined:
    sub sp, sp, #12
    stmdb sp!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r12}
    sub sp, sp, #12
    str lr, [fp, #-12]
.L_insert_lr_stored:

My epilog:

    str r12, [fp]
    add sp, sp, #60
    ldmdb sp, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r12}
    mov sp, fp
.L_insert_sp_defined:
    ldr fp, [sp, #-8]
    ldr pc, [sp, #-12]
.L_insert_end:

And I have:

.text
.section .debug_frame,"",%progbits
.align 2
.Lframe:
    .4byte .LECIE-.LSCIE @ Length of Common Information Entry
.LSCIE:
    .4byte 0xffffffff @ CIE Identifier Tag
    .byte 0x1 @ CIE Version
    .ascii "^@" @ CIE Augmentation
    .uleb128 0x1 @ CIE Code Alignment Factor
    .sleb128 -1 @ CIE Data Alignment Factor
    .byte 0x10 @ CIE RA Column
    .byte 0x9 @ DW_CFA_register
    .uleb128 0x10
    .uleb128 0xe
    .byte 0xc @ DW_CFA_def_cfa
    .uleb128 0xd
    .uleb128 0x0
.align 2
.LECIE:
.LSFDE_insert:
    .4byte .LEFDE_insert-.LASFDE_insert @ FDE Length
.LASFDE_insert:
    .4byte .Lframe @ FDE CIE offset
    .4byte _insert @ FDE initial location
    .4byte .L_insert_end-_insert @ FDE address range
    .byte 0x4 @ DW_CFA_advance_loc4
    .4byte .L_insert_fp_defined-_insert
    .byte 0xd @ DW_CFA_def_cfa_register
    .uleb128 0xb
    .byte 0x4 @ DW_CFA_advance_loc4
    .4byte .L_insert_lr_stored-.L_insert_fp_defined
    .byte 0x5 @ DW_CFA_offset_extended
    .uleb128 0x10
    .uleb128 12
    .byte 0x4 @ DW_CFA_advance_loc4
    .4byte .L_insert_sp_defined-.L_insert_lr_stored
    .byte 0xd @ DW_CFA_def_cfa_register
    .uleb128 0xd
.align 2
.LEFDE_insert:

How can I specify where are function arguments? And locals?


Mitar

Re: Custom call frame description

[Mitar]

Hi!

OK. I figured it out. Canonical frame address is top of the frame. So
where fp register is pointing in my case. I just forgot to describe in
DWARF that I save and where I save previous frame fp so this is the
reason why gdb could not unwind all frames on the stack.

> How can I specify where are function arguments? And locals?

I see that his is not stored in frame section but in subprogram entries.


Mitar

Re: Custom call frame description

[Mitar]

Hi!

Why for:

char foo[] = "bar";

GCC produces for DW_AT_type for subrange (DW_TAG_subrange_type) of the array:

.byte   0x4     @ DW_AT_byte_size
.byte   0x7     @ DW_AT_encoding

That is unsigned four bytes int. Why is not simply a char - the same
type as it is defined in DW_TAG_array_type?


Mitar

Re: Custom call frame description

[Tom Tromey]

>>>>> "Mitar" == Mitar  <mmitar@gmail.com> writes:

Mitar> GCC produces for DW_AT_type for subrange (DW_TAG_subrange_type)
Mitar> of the array:
Mitar> .byte   0x4     @ DW_AT_byte_size
Mitar> .byte   0x7     @ DW_AT_encoding

Mitar> That is unsigned four bytes int. Why is not simply a char - the
Mitar> same type as it is defined in DW_TAG_array_type?

The subrange type defines the range of the array, not the type of the
array's elements.  See the DWARF spec for stuff like this; I found the
answer by just searching for DW_TAG_subrange_type.

Tom

Re: Custom call frame description

[Mitar]

Hi!

On Wed, Jan 27, 2010 at 4:58 PM, Tom Tromey <tromey@redhat.com> wrote:
> The subrange type defines the range of the array, not the type of the
> array's elements.  See the DWARF spec for stuff like this; I found the
> answer by just searching for DW_TAG_subrange_type.

I do read it all the time. It is written in 2.0 version:

The subrange entry may have a DW_AT_type attribute to describe the
type of object of whose
values this subrange is a subset.

And in 3.0 version:

The subrange entry may have a DW_AT_type attribute to describe the
type of object, called the
basis type, of whose values this subrange is a subset.

And from that I understand that it is meant to describe a base type of
an array, that is a type of an each element.


Mitar

Re: Custom call frame description

[Daniel Jacobowitz]

On Wed, Jan 27, 2010 at 08:33:42PM +0100, Mitar wrote:
> And in 3.0 version:
> 
> The subrange entry may have a DW_AT_type attribute to describe the
> type of object, called the
> basis type, of whose values this subrange is a subset.
> 
> And from that I understand that it is meant to describe a base type of
> an array, that is a type of an each element.

No, the *subrange* is a subset of the basis type.  For instance, the
subrange may be the range [0, 7), with a basis type of int because int
is big enough to hold [0, 7).  The type of the subrange is generally
uninteresting for C-like languages.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Custom call frame description

[Tom Tromey]

>>>>> "Mitar" == Mitar  <mmitar@gmail.com> writes:

Tom> The subrange type defines the range of the array, not the type of the
Tom> array's elements.  See the DWARF spec for stuff like this; I found the
Tom> answer by just searching for DW_TAG_subrange_type.

Mitar> The subrange entry may have a DW_AT_type attribute to describe
Mitar> the type of object, called the basis type, of whose values this
Mitar> subrange is a subset.

Mitar> And from that I understand that it is meant to describe a base type of
Mitar> an array, that is a type of an each element.

I can see why you might think that, but I don't think that is the
correct interpretation.

The DW_TAG_subrange_type describes the range of array indices, like
0..4.  Therefore the base type of the subrange is an integer.

The type of elements of the array is described by a different attribute.

Tom

Re: Custom call frame description

[Mitar]

Hi!

On Wed, Jan 27, 2010 at 8:39 PM, Daniel Jacobowitz <dan@codesourcery.com> wrote:
> No, the *subrange* is a subset of the basis type.  For instance, the
> subrange may be the range [0, 7), with a basis type of int because int
> is big enough to hold [0, 7).  The type of the subrange is generally
> uninteresting for C-like languages.

Thanks to both of you.


Mitar