This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

.rodata/.text size issue


I have some questions about .rodata and hope someone could help me.
I am using linario ARM arm-none-eabi-gcc and arm-none-eabi-ld for
cortex-M3 with the following compiler options:
-ggdb -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -fno-common
-fno-builtin -ffunction-sections -Wall -Wstrict-prototypes -Wshadow
-Os -pipe
And linker option: --gc-sections

I have something like this in the linker script:

REGION_ALIAS("REGION_TEXT", sram);
_bootrom_data_area = ORIGIN(sram) + LENGTH(sram) - 24k;
_bootrom_text_area = (_bootrom_data_area - _text_size) & 0xfffffffc - 4;
OUTPUT_ARCH(arm)
SECTIONS
{
    .text (_bootrom_text_area) : {
        _stext = ABSOLUTE(.);
        *(.vectors)
        *(.text .text.*)
        *(.rodata .rodata.*)
        _etext = ABSOLUTE(.);
    } > REGION_TEXT AT > rom

    _text_size = SIZEOF(.text);

    .data (_bootrom_data_area): {
        _sdata = ALIGN(4);
        *(.data .data.*)
        _edata = ALIGN(4);
    } > sram AT > rom
}

The script above would put the .data section at the high end of my
sram, and .text just below it.
However, I found that in some case, when .rodata size is odd, the
whole SIZEOF(.text) will be odd and the whole linking would behave
strange. It looks to be this linker script is scanned multiple times:
1. First time scan get _text_size as the real .text size, which is an odd number
2. Second scan calculated _bootrom_text_area based on this odd number
_text_size and place .text at this odd address. But because the
alignment requirement of the .text section, there were empty bytes
padded in front of the real instructions. Thus make the SIZEOF(.text)
to grow
3. Then the _text_size is calculated again to be the padded size
4. Then _bootrom_text_area is calculated again based on the updated
_text_size. BUT the .text is not moved to this newly calculated
_bootrom_text_area.

So my questions are:
1. Does my analysis above make sense?
2. I did some studying, the odd number of .text comes from .rodata,
this makes some more questions:
3. I found the almost identical ------ const char str[] = "abcdefg";
--------- in two different C files (the variable name and value are
totally different), ends up in different sections, one in .rodata
section but the other one not. How could this happen? I am using the
same flag on two files.
4. In .rodata, some times at the end of the "str" above, it would be
padded to 4 bytes aligned but sometimes it does not. How is this
controlled?

Thanks!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]