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.
--
Michael Eager ea...@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
