[Dwarf-Discuss] armcc DWARF
I have been given a tiny object file created by armcc using DWARF and things make no sense to me so far. dwarfdump (and libdwarf) use the SHT_GROUP section data to associate sections to their group. This is a .o, not a fully linked executable or shared-library. (libdwarf assigns group numbers itself. group 1 is non-dwo .debug sections) (any .dwo sections present would be shown as group 2 if not listed in a section-group header, but no such are present here) Here is dwarfdump/libdwarf/s reading of the sections and section-group sections. Section Groups data Number of Elf-like sections: 35 Number of groups :5 Group to print :3 Count of map entries : 15 [index] group section [0]1 4 .debug_frame [1]1 5 .debug_info [2]1 6 .debug_info [3]1 7 .debug_line [4]1 8 .debug_line [5]1 9 .debug_loc [6]110 .debug_macinfo [7]111 .debug_pubnames [8]313 .debug_info [9]314 .debug_line [ 10]416 .debug_info [ 11]518 .debug_info [ 12]519 .debug_line [ 13]520 .debug_macinfo [ 14]622 .debug_abbrev There are two .debug_info not in any group (called group 1 by libdwarf). There is only one .debug_abbrev and it is in group six. How is one to make sense of this? Which .debug_line (sec 7 or 8)would be referred to from section 6 debug_line? How would one know? Why is .debug_abbrev in a group by itself? I would appreciate any information on how the sections tie together... how is a reader supposed to know what goes with what? Thanks for any hints. David Anderson -- Duct tape is like the force. It has a light side, a dark side, and it holds the universe together -- Carl Zwanzig ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] armcc DWARF
On 05/22/2018 02:33 PM, David Anderson via Dwarf-Discuss wrote: I have been given a tiny object file created by armcc using DWARF and things make no sense to me so far. dwarfdump (and libdwarf) use the SHT_GROUP section data to associate sections to their group. This is a .o, not a fully linked executable or shared-library. (libdwarf assigns group numbers itself. group 1 is non-dwo .debug sections) (any .dwo sections present would be shown as group 2 if not listed in a section-group header, but no such are present here) Here is dwarfdump/libdwarf/s reading of the sections and section-group sections. Section Groups data Number of Elf-like sections: 35 Number of groups :5 Group to print :3 Count of map entries : 15 [index] group section [0]1 4 .debug_frame [1]1 5 .debug_info [2]1 6 .debug_info [3]1 7 .debug_line [4]1 8 .debug_line [5]1 9 .debug_loc [6]110 .debug_macinfo [7]111 .debug_pubnames [8]313 .debug_info [9]314 .debug_line [ 10]416 .debug_info [ 11]518 .debug_info [ 12]519 .debug_line [ 13]520 .debug_macinfo [ 14]622 .debug_abbrev There are two .debug_info not in any group (called group 1 by libdwarf). There is only one .debug_abbrev and it is in group six. How is one to make sense of this? Which .debug_line (sec 7 or 8)would be referred to from section 6 debug_line? How would one know? Why is .debug_abbrev in a group by itself? I would appreciate any information on how the sections tie together... how is a reader supposed to know what goes with what? Can you post the output of readelf? -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] armcc DWARF
On 05/22/2018 04:18 PM, Michael Eager wrote:
> On 05/22/2018 02:33 PM, David Anderson via Dwarf-Discuss wrote:
>>
>> I have been given a tiny object file created by armcc
>> using DWARF and things make no sense to me so far.
>>
>> dwarfdump (and libdwarf) use the SHT_GROUP section data to associate
>> sections to their group. This is a .o, not a fully linked executable or
>> shared-library.
>>
>> (libdwarf assigns group numbers itself. group 1 is non-dwo .debug
>> sections)
>> (any .dwo sections present would be shown as group 2
>> if not listed in a section-group header, but no such are present here)
>>
>>
> Can you post the output of readelf?
>
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00 00 00
0 0 0
[ 1] .text PROGBITS 34 08 00 AX
0 0 4
[ 2] .arm_vfe_header PROGBITS 3c 04 00
0 0 4
[ 3] .comment PROGBITS 40 7a 00
0 0 1
[ 4] .debug_frame PROGBITS ba 44 00
0 0 1
[ 5] .debug_info PROGBITS fe 98 00
0 0 1
[ 6] .debug_info PROGBITS 000196 e0 00
[ 7] .debug_line PROGBITS 000276 2c 00
0 0 1
[ 8] .debug_line PROGBITS 0002a2 38 00
0 0 1
[ 9] .debug_loc PROGBITS 0002da 50 00
0 0 1
[10] .debug_macinfo PROGBITS 00032a 0002cc 00
0 0 1
[11] .debug_pubnames PROGBITS 0005f6 20 00
0 0 1
[12] __ARM_grp.a.h.2_sq_$0QbXG$5KW3_20 GROUP
000618 0c 04 23 17 4
[13] .debug_info PROGBITS 000624 a8 00 G
0 0 1
[14] .debug_line PROGBITS 0006cc 28 00 G
0 0 1
[15] __ARM_grp.b.h.2_ws_eYI6SD7WPJ9_50 GROUP
0006f4 08 04 23 18 4
[16] .debug_info PROGBITS 0006fc ac 00 G
0 0 1
[17] __ARM_grp.test.c.2_cx_sjeCPPJ9rd8_90 GROUP
0007a8 10 04 23 19 4
[18] .debug_info PROGBITS 0007b8 9c 00 G
0 0 1
[19] .debug_line PROGBITS 000854 38 00 G
0 0 1
[20] .debug_macinfo PROGBITS 00088c 10 00 G
0 0 1
[21] __ARM_grp..debug_abbrev.group.2_Am_lbphKItke$2_00
GROUP 00089c 08 04 23 13 4
[22] .debug_abbrev PROGBITS 0008a4 0005a4 00 G
0 0 1
[23] .symtab SYMTAB 000e48 000190 10
33 13 4
[24] .rel.debug_frame REL 000fd8 10 08
23 4 4
[25] .rel.debug_info REL 000fe8 18 08
23 5 4
[26] .rel.debug_info REL 001000 68 08
23 6 4
[27] .rel.debug_line REL 001068 08 08
23 8 4
[28] .rel.debug_pubnames REL 001070 08 08
23 11 4
[29] .rel.debug_info REL 001078 10 08
23 13 4
[30] .rel.debug_info REL 001088 18 08
23 16 4
[31] .rel.debug_info REL 0010a0 20 08
23 18 4
[32] .shstrtab STRTAB 0010c0 000172 00
0 0 1
[33] .strtab STRTAB 001232 00037e 00
0 0 1
[34] .ARM.attributes ARM_ATTRIBUTES 0015b0 45 00
0 0 1
I'll email you the test case object file, Mike, so you can see the
group records etc.
Here is the test source:
#include "a.h"
#include "b.h"
void set_point(struct POINT *point, NUMBER x, NUMBER y)
{
point->x = x;
point->y = y;
}
q3 1708: cat a.h
typedef float NUMBER;
q3 1709: cat b.h
struct POINT {
NUMBER x;
NUMBER y;
};
DavidA.
--
There's no chance that the iPhone is going to get any significant market share.
-- Steve Ballmer
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] armcc DWARF
On 05/22/2018 04:34 PM, David Anderson wrote:
On 05/22/2018 04:18 PM, Michael Eager wrote:
On 05/22/2018 02:33 PM, David Anderson via Dwarf-Discuss wrote:
I have been given a tiny object file created by armcc
using DWARF and things make no sense to me so far.
dwarfdump (and libdwarf) use the SHT_GROUP section data to associate
sections to their group. This is a .o, not a fully linked executable or
shared-library.
(libdwarf assigns group numbers itself. group 1 is non-dwo .debug
sections)
(any .dwo sections present would be shown as group 2
if not listed in a section-group header, but no such are present here)
Can you post the output of readelf?
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00 00 00
0 0 0
[ 1] .text PROGBITS 34 08 00 AX
0 0 4
[ 2] .arm_vfe_header PROGBITS 3c 04 00
0 0 4
[ 3] .comment PROGBITS 40 7a 00
0 0 1
[ 4] .debug_frame PROGBITS ba 44 00
0 0 1
[ 5] .debug_info PROGBITS fe 98 00
0 0 1
[ 6] .debug_info PROGBITS 000196 e0 00
[ 7] .debug_line PROGBITS 000276 2c 00
0 0 1
[ 8] .debug_line PROGBITS 0002a2 38 00
0 0 1
[ 9] .debug_loc PROGBITS 0002da 50 00
0 0 1
[10] .debug_macinfo PROGBITS 00032a 0002cc 00
0 0 1
[11] .debug_pubnames PROGBITS 0005f6 20 00
0 0 1
[12] __ARM_grp.a.h.2_sq_$0QbXG$5KW3_20 GROUP
000618 0c 04 23 17 4
[13] .debug_info PROGBITS 000624 a8 00 G
0 0 1
[14] .debug_line PROGBITS 0006cc 28 00 G
0 0 1
[15] __ARM_grp.b.h.2_ws_eYI6SD7WPJ9_50 GROUP
0006f4 08 04 23 18 4
[16] .debug_info PROGBITS 0006fc ac 00 G
0 0 1
[17] __ARM_grp.test.c.2_cx_sjeCPPJ9rd8_90 GROUP
0007a8 10 04 23 19 4
[18] .debug_info PROGBITS 0007b8 9c 00 G
0 0 1
[19] .debug_line PROGBITS 000854 38 00 G
0 0 1
[20] .debug_macinfo PROGBITS 00088c 10 00 G
0 0 1
[21] __ARM_grp..debug_abbrev.group.2_Am_lbphKItke$2_00
GROUP 00089c 08 04 23 13 4
[22] .debug_abbrev PROGBITS 0008a4 0005a4 00 G
0 0 1
[23] .symtab SYMTAB 000e48 000190 10
33 13 4
[24] .rel.debug_frame REL 000fd8 10 08
23 4 4
[25] .rel.debug_info REL 000fe8 18 08
23 5 4
[26] .rel.debug_info REL 001000 68 08
23 6 4
[27] .rel.debug_line REL 001068 08 08
23 8 4
[28] .rel.debug_pubnames REL 001070 08 08
23 11 4
[29] .rel.debug_info REL 001078 10 08
23 13 4
[30] .rel.debug_info REL 001088 18 08
23 16 4
[31] .rel.debug_info REL 0010a0 20 08
23 18 4
[32] .shstrtab STRTAB 0010c0 000172 00
0 0 1
[33] .strtab STRTAB 001232 00037e 00
0 0 1
[34] .ARM.attributes ARM_ATTRIBUTES 0015b0 45 00
0 0 1
I'll email you the test case object file, Mike, so you can see the
group records etc.
Here is the test source:
#include "a.h"
#include "b.h"
void set_point(struct POINT *point, NUMBER x, NUMBER y)
{
point->x = x;
point->y = y;
}
q3 1708: cat a.h
typedef float NUMBER;
q3 1709: cat b.h
struct POINT {
NUMBER x;
NUMBER y;
};
I compiled the test with ARM-GCC. Here is what it generates:
Section Headers:
[Nr] Name TypeAddr OffSize ES Flg
Lk Inf Al
[ 0] NULL 00 00 00
0 0 0
[ 1] .text PROGBITS 34 40 00 AX
0 0 4
[ 2] .rel.text REL 000440 08 08 I
17 1 4
[ 3] .data PROGBITS 74 00 00 WA
0 0 1
[ 4] .bss NOBITS 74 00 00 WA
0 0 1
[ 5] .debug_info PROGBITS 74 a3 00
0 0 1
[ 6] .rel.debug_info REL 000448 60 08 I
17 5 4
[ 7] .debug_abbrev PROGBITS 000117 97 00
0 0 1
[ 8] .debug_arangesPROGBITS 0001ae 20 00
0 0 1
[ 9] .rel.debug_arange REL 0004a8 10 08 I
17 8 4
[10] .debug_line PROGBITS 0001ce 4b 00
0 0 1
[11] .r
