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 00000000 000000 000000 00
>> 0 0 0
>> [ 1] .text PROGBITS 00000000 000034 000008 00 AX
>> 0 0 4
>> [ 2] .arm_vfe_header PROGBITS 00000000 00003c 000004 00
>> 0 0 4
>> [ 3] .comment PROGBITS 00000000 000040 00007a 00
>> 0 0 1
>> [ 4] .debug_frame PROGBITS 00000000 0000ba 000044 00
>> 0 0 1
>> [ 5] .debug_info PROGBITS 00000000 0000fe 000098 00
>> 0 0 1
>> [ 6] .debug_info PROGBITS 00000000 000196 0000e0 00
>> [ 7] .debug_line PROGBITS 00000000 000276 00002c 00
>> 0 0 1
>> [ 8] .debug_line PROGBITS 00000000 0002a2 000038 00
>> 0 0 1
>> [ 9] .debug_loc PROGBITS 00000000 0002da 000050 00
>> 0 0 1
>> [10] .debug_macinfo PROGBITS 00000000 00032a 0002cc 00
>> 0 0 1
>> [11] .debug_pubnames PROGBITS 00000000 0005f6 000020 00
>> 0 0 1
>> [12] __ARM_grp.a.h.2_sq0000_$0QbXG$5KW3_200000 GROUP
>> 00000000 000618 00000c 04 23 17 4
>> [13] .debug_info PROGBITS 00000000 000624 0000a8 00 G
>> 0 0 1
>> [14] .debug_line PROGBITS 00000000 0006cc 000028 00 G
>> 0 0 1
>> [15] __ARM_grp.b.h.2_ws0000_eYI6SD7WPJ9_500000 GROUP
>> 00000000 0006f4 000008 04 23 18 4
>> [16] .debug_info PROGBITS 00000000 0006fc 0000ac 00 G
>> 0 0 1
>> [17] __ARM_grp.test.c.2_cx0000_sjeCPPJ9rd8_900000 GROUP
>> 00000000 0007a8 000010 04 23 19 4
>> [18] .debug_info PROGBITS 00000000 0007b8 00009c 00 G
>> 0 0 1
>> [19] .debug_line PROGBITS 00000000 000854 000038 00 G
>> 0 0 1
>> [20] .debug_macinfo PROGBITS 00000000 00088c 000010 00 G
>> 0 0 1
>> [21] __ARM_grp..debug_abbrev.group.2_Am0000_lbphKItke$2_000000
>> GROUP 00000000 00089c 000008 04 23 13 4
>> [22] .debug_abbrev PROGBITS 00000000 0008a4 0005a4 00 G
>> 0 0 1
>> [23] .symtab SYMTAB 00000000 000e48 000190 10
>> 33 13 4
>> [24] .rel.debug_frame REL 00000000 000fd8 000010 08
>> 23 4 4
>> [25] .rel.debug_info REL 00000000 000fe8 000018 08
>> 23 5 4
>> [26] .rel.debug_info REL 00000000 001000 000068 08
>> 23 6 4
>> [27] .rel.debug_line REL 00000000 001068 000008 08
>> 23 8 4
>> [28] .rel.debug_pubnames REL 00000000 001070 000008 08
>> 23 11 4
>> [29] .rel.debug_info REL 00000000 001078 000010 08
>> 23 13 4
>> [30] .rel.debug_info REL 00000000 001088 000018 08
>> 23 16 4
>> [31] .rel.debug_info REL 00000000 0010a0 000020 08
>> 23 18 4
>> [32] .shstrtab STRTAB 00000000 0010c0 000172 00
>> 0 0 1
>> [33] .strtab STRTAB 00000000 001232 00037e 00
>> 0 0 1
>> [34] .ARM.attributes ARM_ATTRIBUTES 00000000 0015b0 000045 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 00000000 000000 000000 00 0 0 0
> [ 1] .text PROGBITS 00000000 000034 000040 00 AX
> 0 0 4
> [ 2] .rel.text REL 00000000 000440 000008 08 I
> 17 1 4
> [ 3] .data PROGBITS 00000000 000074 000000 00 WA
> 0 0 1
> [ 4] .bss NOBITS 00000000 000074 000000 00 WA
> 0 0 1
> [ 5] .debug_info PROGBITS 00000000 000074 0000a3 00 0 0 1
> [ 6] .rel.debug_info REL 00000000 000448 000060 08 I
> 17 5 4
> [ 7] .debug_abbrev PROGBITS 00000000 000117 000097 00 0 0 1
> [ 8] .debug_aranges PROGBITS 00000000 0001ae 000020 00 0 0 1
> [ 9] .rel.debug_arange REL 00000000 0004a8 000010 08 I
> 17 8 4
> [10] .debug_line PROGBITS 00000000 0001ce 00004b 00 0 0 1
> [11] .rel.debug_line REL 00000000 0004b8 000008 08 I
> 17 10 4
> [12] .debug_str PROGBITS 00000000 000219 000090 01 MS
> 0 0 1
> [13] .comment PROGBITS 00000000 0002a9 000031 01 MS
> 0 0 1
> [14] .debug_frame PROGBITS 00000000 0002dc 000030 00 0 0 4
> [15] .rel.debug_frame REL 00000000 0004c0 000010 08 I
> 17 14 4
> [16] .ARM.attributes ARM_ATTRIBUTES 00000000 00030c 00002a 00 0 0 1
> [17] .symtab SYMTAB 00000000 000338 0000f0 10 18
> 14 4
> [18] .strtab STRTAB 00000000 000428 000015 00 0 0 1
> [19] .shstrtab STRTAB 00000000 0004d0 0000a6 00 0 0 1
>
> One, and only one, .debug_info, .debug_line, etc.
>
> If the .debug_info section is generated in multiple pieces, IMO a
> reasonable assembler would combine the pieces into a single section.
>
> A quick glance at the SVR4 ELF doc does not say that the names of
> sections in an ELF file must be unique. I can't guess whether this
> is an oversight or intentional, but I always assumed that any given
> section name would only appear once in an ELF file.
>
> The thinking may be that if the linker is going to coalesce like-
> named sections from multiple object files, it might as well do
> the same for like-named sections in the same object file.
>
It's perfectly legal to have multiple sections with the same name in an
ELF file. All relevant inter section data is conveyed by the section's
unique index. Having identical names for sections is important for
getting link ordering correct. And also, for dwarf because the section
names have specific meanings that are not otherwise conveyed by
attribute data.
Writing multiple debug sections allows unneeded sections to be correctly
discarded by the linker - making the job much easier for the debugger.
This is useful for things like C++ classes that lack key functions, or
inline functions that have repeated definitions in each object file that
needs them. The arm tools use section groups for debug information to
ensure that if one part gets discarded the whole group can be dropped.
R.
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
