This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Section (.sdata2) being omitted but SIZEOF(.sdata2) is not zero?
- From: Douglas Graham <douglas dot graham at ericsson dot com>
- To: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Sat, 18 Jan 2014 22:43:15 +0000
- Subject: Section (.sdata2) being omitted but SIZEOF(.sdata2) is not zero?
- Authentication-results: sourceware.org; auth=none
Hello,
When using 2.24 (and earlier) ppc-eabi ld, our (simplified) linker script looks something like this:
SECTIONS
{
.header :
{
KEEP (*(.header))
. = (. + 63) & ~ 63;
} > ram
.text :
{
*(.text)
.
}
.sdata2 :
{
__start_of_sdata2 = ABSOLUTE(.);
PROVIDE (_SDA2_BASE_ = .);
*(.sdata2)
.
__end_of_sdata2 = ABSOLUTE(.);
. = ((__end_of_sdata2 + 4095) & ~ 4095) - __start_of_sdata2 ;
} > ram
.data :
{
.
}
}
__CODE_SIZE = SIZEOF(.text) + SIZEOF(.sdata2);
Most of the time, there's no actual content in .sdata2 so the only thing in that output section is the padding (there's probably a better way to do this, but this has been working for a long time so we're reluctant to touch it). We've recently started using the -gc-sections linker option. This works most of the time, but the problem is that sometimes (as far as I can tell, only when the size of .header plus .text is a multiple of 512 bytes) the output elf file does not contain a .sdata2 section. This would be fine, but what isn't fine is that SIZEOF(.sdata2) is not zero. __CODE_SIZE is the size of .text plus the size of the phantom .sdata2 section that wasn't actually output. .data is still aligned on a 4KB boundary, but there's a gap between the end of .text and the beginning of .data that is not reflected in any output elf section. The problem is that we have a tool that processes the elf file that expects that there is actually __CODE_SIZE bytes of content in .text and .sdata2 ELF sections, but since .sdata2 was not output to the elf output file, this is not the case and our post-processing tool breaks.
Usually we do get an .sdata2 section in the output file that contains just the padding, but occasionally we do not. I'm trying to understand the circumstances under which .sdata2 is not output so I can avoid them. Can anybody explain what might be happening here? Is this a bug in the linker? It seems to me that it probably is. If SIZEOF(.sdata2) is not zero, shouldn't there actually be a .sdata2 output section? Is there any simple workaround for this?
Thanks,
Doug