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

[Douglas Graham <douglas dot graham at ericsson dot com>]

> In the scenario that does not work, expld.result.value is zero, whereas when
> it does work, that value is non-zero.  I think the reason this bit of code
> decided that no padding was necessary is because the value of "dot" passed
> into the outermost occurrence of lang_size_sections_1() in the backtrace
> above is 0x1c80000, ie: it's page aligned.  I don't know what the value of dot
> represents in the code at that point.  This invocation of lang_size_sections_1
> is related to .sdata2 (output_section_statement->name is ".sdata2") and
> once this link is complete, there is no output .sdata2 section and .data is at
> 01c7a000.  0x1c80000 is an address in the middle of the final .data section.  I'm
> guessing that some bit of code looked at 0x1c80000 and decided that no
> padding was necessary because of all those zeroes, even though that
> location counter is going to be adjusted later?

I think the reason that the dot used for some of the expression calculations in .sdata is seemingly incorrect (0x1c80000 instead of closer to 0x1c7a000) is that the size computed for the preceding .text output section via calls to size_input_section() uses the "unrelaxed" sizes of .eh_frame sections from various object files.  Stepping through calls to this routine, I can see it computing correct values of dot for everything up to .eh_frame (ie: the values I see in the debugger match those from the map file) but once it hits .eh_frame sections, dot in the code is advanced by the "size before relaxing", whereas that addresses in the map file are advanced by the size after relaxing. For example, the map file contains these first few .eh_frame input sections:

 .eh_frame      0x0000000001c62550        0x2c lib/gcc/powerpc-eabi/3.4.4/nof/libgcc.a(_udivdi3.o)
 .eh_frame      0x0000000001c6257c        0x24 lib/gcc/powerpc-eabi/3.4.4/nof/libgcc.a(_umoddi3.o)
                                                                              0x34 (size before relaxing)
 .eh_frame      0x0000000001c625a0        0x1f4 lib/nof/libstdc++.a(functexcept.o)
 .eh_frame      0x0000000001c62794        0x00 lib/nof/libstdc++.a(globals_io.o)
                                                                              0x48 (size before relaxing)
 .eh_frame      0x0000000001c62794        0xb4 lib/nof/libstdc++.a(ios_failure.o)

In the code, dot starts as 0x1c62550 when it starts processing .eh_frame sections, changes to 0x1c6257c after processing the first section, but then to 0x1c625b0 after the second and 0x1c627a4 after the third and then to 0x1c627ec after the fourth.

What does relaxing mean in this context?

The size computation I'm referring to  is that done from here:

#0  size_input_section (this_ptr=0x95cbd20, output_section_statement=0x7de760, fill=0x0, dot=29763772)
    at ldlang.c:4596
#1  0x0000000000414ad4 in lang_size_sections_1 (prev=0x95cbd20, output_section_statement=0x7de760,
    fill=0x0, dot=29763564, relax=0x0, check_regions=0) at ldlang.c:5171
#2  0x0000000000414a1e in lang_size_sections_1 (prev=0x7d5090, output_section_statement=0x7de760,
    fill=0x0, dot=29762896, relax=0x0, check_regions=0) at ldlang.c:5143
#3  0x00000000004141ce in lang_size_sections_1 (prev=0x7de6b0, output_section_statement=0x7de600,
    fill=0x0, dot=23330880, relax=0x0, check_regions=0) at ldlang.c:4924
#4  0x0000000000414f51 in one_lang_size_sections_pass (relax=0x0, check_regions=0) at ldlang.c:5350
#5  0x0000000000412098 in strip_excluded_output_sections () at ldlang.c:3848
#6  0x0000000000420ae2 in before_allocation_default () at ldemul.c:241
#7  0x0000000000428515 in gldelf32ppc_before_allocation () at eelf32ppc.c:1300
#8  0x0000000000426788 in ppc_before_allocation () at eelf32ppc.c:198
#9  0x0000000000420716 in ldemul_before_allocation () at ldemul.c:78
#10 0x00000000004173df in lang_process () at ldlang.c:6737
#11 0x000000000041afba in main (argc=1101, argv=0x7dc170) at ./ldmain.c:411

Am I right in being suspicious of these bogus looking addresses or have I gone off into the weeds?

I'm thinking now that since we compile all our code with -fno-exceptions anyway, perhaps we could save a bit more space (almost 100KB) and avoid this problem by stripping the .eh_frame sections from library code.  That'd probably be slightly messy to implement though.  Maybe easiest to assign all the input .eh_frame sections to the /DISCARD/ output section.

--Doug