On 23/05/18 01:07, Michael Eager via Dwarf-Discuss wrote:
> 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 Type Addr Off Size 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
