Re: Section (.sdata2) being omitted but SIZEOF(.sdata2) is not zero?

[Alan Modra <amodra at gmail dot com>]

On Mon, Jan 20, 2014 at 06:19:44PM +0000, Douglas Graham wrote:
> > 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

These are linker created sections.

> 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?

Yes, I don't expect they are causing any trouble.  Normally .glink is
hidden away in .text.

> 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

What's really odd about the above is that the linker map file is
output after the object file has been written (well, the file may not
actually be on disk, but logically its been written).  So for .sdata2
to not appear in the output file its size must have been zero at that
point, I think.  Later we make another pass over the script to output
the map file and the size magically increases.  That is possible with
an evil linker script.  I know I could write one that changed
placement and size of a section on every pass over the script.  All
you need is some alignment that depends on forward references, and a
little trickery to avoid the linker's forward reference checking..

Care to post your full linker script?

> 
> 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
> 

-- 
Alan Modra
Australia Development Lab, IBM