ARM + gcc: don't use one big .rodata section

Question

I want to compile a program with gcc with link time optimization for an ARM processor. When I compile without LTO, the system gets compiled. When I enable LTO (with -flto), I get the following assembler-error:

Error: invalid literal constant: pool needs to be closer

Looking around the web I found out that this has something to do with the constants in my system, which are placed in a special section called .rodata, which is called a constant pool and is placed right after the .text section in my system. It seems that when compiling with LTO because of inlining and other optimizations this .rodata section gets too far away from the instructions, so that the addressing of the constants is not possible anymore. Is it possible to place the constants right after the function that uses them? Or is it possible to use another addressing mode so the .rodata section can still be addressed? Thanks.

Answer 1

This is an assembler message, not a linker message, so this happens before sections are generated.

The assembler has a pseudo instruction for loading constants into registers:

    ldr r0, =0x12345678

this is expanded into

    ldr r0, [constant_12345678, r15]
    ...
    bx lr
constant_12345678:
    dw 0x12345678

The constant pool usually follows the return instruction. With function inlining, the function can get long enough that the return instruction is too far away; unfortunately, the compiler has no idea of the distance between memory addresses, and the assembler has no idea of control flow other than "flow does not pass beyond the return instruction, so it is safe to emit the constant pool here".

Unfortunately, there is no good solution at the moment.

You could try an asm block containing

    b 1f
    .ltorg
1:

This will force-emit the constant pool at this point, at the cost of an extra branch instruction.

It may be possible to instruct the assembler to omit the branch if the constant pool is empty, but I cannot test that at the moment, so this is probably not valid:

    .if (2f - 1f)
    .b 2f
    .endif
1:
    .ltorg
2: