[Dwarf-Discuss] compilation unit base address related questions
Michael Eager
eager@eagercon.com
Tue May 26 19:13:19 GMT 2009
Stoyan Shopov wrote:
> Hi, guys, this is my first post on this mailing list. English is not my
> native language, so please don't be too harsh if I err too much and you
> have a tough time following me.
>
> I have a question regarding the usage of compilation unit base address
> computaions. The bottom line of my copy of the dwarf 3 standard document
> reads "december 2005" - hope that's the latest one, and on page number
> 41 - that should be the very last paragraph of section "3.1.1. Normal
> and partial compilation unit entries" (xpdf reports this as page 53),
> written is (verbatim):
>
> "The base address of a compilation unit is defined as the value of the
> DW_AT_low_pc attribute,
> if present; otherwise, it is undefined. If the base address is
> undefined, then any DWARF entry or
> structure defined in terms of the base address of that compilation unit
> is not valid."
DW_AT_low_pc gives the address where the *code* for a compilation unit
or a function is loaded. It is not related to the location of *data*.
> That said, on page 26 (xpdf says 38) - section "2.6.6. Location Lists",
> I can read:
> "Location lists are used in place of location expressions whenever the
> object whose location is
> being described can change location during its lifetime."
Location lists describe where *data* resides over its lifetime.
This is most usually because the latest copy of the data is in memory
for part of its lifetime and in one or more registers for part.
> My experience says C-language automatic variables, and frame base
> locations are just one such artefacts that can change locations during
> their lifetimes (please correct me if I am wrong!), so I decided to see
> what gcc does with this concoction - a compilation unit spanning
> non-contiguous address ranges, along with location lists describing the
> frame base address of a routine.
While the frame base does change depending on the call sequence,
it is usually fixed relative to the register contents on entry to
a function. The location list for the frame base tells how to
compute the frame base depending on the PC location.
Automatic variables are on the stack, usually at a fixed offset from
the frame base. While the absolute location may change, the relative
location (frame+offset) doesn't change.
> I coded this simple C program:
>
> void sec1 (void) __attribute__ ((section (".sec1")));
> void sec1 (void) {}
> void sec2 (void) __attribute__ ((section (".sec2")));
> void sec2 (void) {}
>
> intending to create two different program sections containing two (very
> empty) routines; I compiled this with:
>
> gcc -g -nostdlib -o prog.elf prog.c
>
> Then, I ran dwarfdump -a prog.elf, which said, amongst other things:
> .debug_info
>
> COMPILE_UNIT<header overall offset = 0>:
> <0>< 11> DW_TAG_compile_unit
> DW_AT_stmt_list 0
> DW_AT_producer GNU C 4.1.2 (Gentoo 4.1.2 p1.1)
> DW_AT_language DW_LANG_C89
> DW_AT_name sec.c
> DW_AT_comp_dir
> /home/shopov/src/gear-201108/engine/target_test
>
> LOCAL_SYMBOLS:
> <1>< 103> DW_TAG_subprogram
> DW_AT_external yes(1)
> DW_AT_name sec1
> DW_AT_decl_file 1
> /home/shopov/src/gear-201108/engine/target_test/sec.c
> DW_AT_decl_line 2
> DW_AT_prototyped yes(1)
> DW_AT_low_pc 0x8048094
> DW_AT_high_pc 0x8048099
> DW_AT_frame_base <loclist with 3 entries follows>
> [ 0]<lowpc=0x8048094><highpc=0x8048095>DW_OP_breg4+4
> [ 1]<lowpc=0x8048095><highpc=0x8048097>DW_OP_breg4+8
> [ 2]<lowpc=0x8048097><highpc=0x8048099>DW_OP_breg5+8
> <1>< 125> DW_TAG_subprogram
> DW_AT_external yes(1)
> DW_AT_name sec2
> DW_AT_decl_file 1
> /home/shopov/src/gear-201108/engine/target_test/sec.c
> DW_AT_decl_line 4
> DW_AT_prototyped yes(1)
> DW_AT_low_pc 0x8048099
> DW_AT_high_pc 0x804809e
> DW_AT_frame_base <loclist with 3 entries follows>
> [ 0]<lowpc=0x8048099><highpc=0x804809a>DW_OP_breg4+4
> [ 1]<lowpc=0x804809a><highpc=0x804809c>DW_OP_breg4+8
> [ 2]<lowpc=0x804809c><highpc=0x804809e>DW_OP_breg5+8
>
> ----------------------- more follows
>
> Easily seen is that any mentions of DW_AT_low_pc or DW_AT_ranges are
> forfeit in the COMPILE_UNIT description
> DIE.
The DW_AT_low_pc and DW_AT_high_pc values indicate where the functions
sec1() and sec2() are loaded into memory.
> My question is - is this correct? After all, the result of my efforts is
> a perfectly valid executable file, the frame base
> lists look perfectly all right as well (they don't overlap, are at sane
> virtual address locations for my operating
> environment, etc.), yet - according to standard (as I get it) - as the
> value of the DW_AT_low_pc attribute,
> is NOT present, the base address of the compilation unit is NOT defined
> (i.e. it is undefined).
Why do you say DW_AT_low_pc is not defined? Your example shows this
attribute for both sec1() and sec2().
> If it is undefined,
> then any DWARF entry defined in terms of the base address of that
> compilation unit - which (as I get it - the frame base in this
> minimalistic example is) is not valid. How come that?
Compilation units may have DW_AT_low_pc, but that is optional.
What DWARF entry do you believe is not well defined?
> Please note that this example may be probably invalid for execution
> (read - can't run). It segfaults at my premises.
The DWARF in your example says that when you enter sec1(), at 0x8048094,
the frame base is in (breg4+4). After stepping to 0x8048095, the frame
base is in (breg4+8), and at 0x8048097 through the end of the function,
at 0x8048099, the frame base is in (breg5+8).
> It's apparent that I am missing quite some things - please, guys, direct me.
>
> Best regards to all of you, guys, and greetings from Bulgaria,
> Health and luck to you all,
And greetings from sunny California!
--
Michael Eager eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
More information about the Dwarf-discuss
mailing list