[Dwarf-Discuss] armcc DWARF

Wed May 23 08:56:46 GMT 2018

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.