This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: Section (.sdata2) being omitted but SIZEOF(.sdata2) is not zero?
- From: Douglas Graham <douglas dot graham at ericsson dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 20 Jan 2014 18:19:44 +0000
- Subject: RE: Section (.sdata2) being omitted but SIZEOF(.sdata2) is not zero?
- Authentication-results: sourceware.org; auth=none
- References: <E36F5062C1BCFC48B8230995895548DF02C35784 at eusaamb109 dot ericsson dot se> <E36F5062C1BCFC48B8230995895548DF02C357A9 at eusaamb109 dot ericsson dot se> <20140119092749 dot GJ5390 at bubble dot grove dot modra dot org> <E36F5062C1BCFC48B8230995895548DF02C359DC at eusaamb109 dot ericsson dot se> <E36F5062C1BCFC48B8230995895548DF02C359F8 at eusaamb109 dot ericsson dot se> <20140120045856 dot GL5390 at bubble dot grove dot modra dot org>
> Nothing you've shown so far turns on any lightbulbs. Have you looked at a
> linker map file? Sometimes that will help point out something you haven't
> thought might be happening, eg. orphan sections.
I'm not sure if there's an easy way to find orphan sections but by doing it the hard way (looking for input sections mentioned in the map file that aren't mentioned in the linker script), I found
.glink 0x0000000001c79e00 0x0
.glink 0x0000000000000000 0x0 osemain_rus5.o5
.iplt 0x0000000001ccd750 0x0
.iplt 0x0000000000000000 0x0 osemain_rus5.o5
I don't know where these are coming from because dumping the headers of osemain_rus5.o doesn't show either of those sections. Maybe these are in that object file because that's the one that contains "main"? I'll have to read the fine print in the manual again about the implications of orphan sections, but I guess that since these ones are zero length, they don't really matter?
I'm not sure what else to look for in there. The map file does have a section for the .sdata2 output section even though the elf contains no such section:
.glink 0x0000000001c79e00 0x0
.glink 0x0000000000000000 0x0 osemain_rus5.o5
.sdata2 0x0000000001c79e00 0x200
0x0000000001c79e00 __start_of_sdata2 = ABSOLUTE (.)
0x0000000001c79e00 PROVIDE (_SDA2_BASE_, .)
*(.sdata2)
*(.sdata2.*)
*(.gnu.linkonce.s2.*)
*(.sbss2)
*(.sbss2.*)
*(.gnu.linkonce.sb2.*)
0x0000000001c79e00 __end_of_sdata2 = ABSOLUTE (.)
0x0000000001c79e00 . = ((. + 0x3) & 0xfffffffffffffffc)
0x0000000000000200 . = (((__end_of_sdata2 + 0xfff) & 0xfffffffffffff000) - __start_of_sdata2)
*fill* 0x0000000001c79e00 0x200
.data 0x0000000001c7a000 0x45698
I included .glink above to show that that orphan section was apparently output just before .sdata2
I'm thinking that I might now have gotten up the courage to add some instrumentation to ld to try to figure this out. If it's outputting a map file entry for .sdata2 but not an elf section, maybe I'll be able to figure out why it seems to be losing track of .sdata2 between outputting the map and outputting the elf.
Note that .sdata is not in the " Discarded input sections" section of the map file.
--Doug