GNU LD filling unused space

2

I'm trying to understand the behaviour of the GNU linker and how sections are treated.

I'm editing the stm32_flash.ld file in this stm32 project.

When I modify the linker script to put the following as the first section:

.my_test :
{
    . = ALIGN(4);
    KEEP(*(.my_test))
    LONG(0xdeadbeef);
    . = ALIGN(4);
} >FLASH

I can see the built binary has the 0xdeadbeef as the first bytes, as I would expect.

$ od -An -tx1 -w1 -v build/program.bin | head
ef
be
ad
de
00
a0
00
20
31
5e

However, if I use the following as the first section:

.my_test :
{
        . = ALIGN(8);
        KEEP(*(.my_test))
        FILL(0xDEADBEEF)
        . = 0x8000;
} > FLASH

Then it looks like the linker completely skips this section:

$ od -An -tx1 -w1 -v build/program.bin | head
00
a0
00
20
2d
de
00
08
c1
d9

But I would expect the first 0x8000 bytes to be filled with 0xdeadbeef. Why is the linker ignoring my section?

linker
ld
asked on Stack Overflow Jul 27, 2017 by Sam • edited Jul 27, 2017 by too honest for this site

1 Answer

0

Does any of your code "emit" to section .my_test?

With your first example, there was a command to "emit" four bytes into that section with the LONG command.

With your second example, there is no explicit "emit" command. FILL only takes effect when it knows how much to fill: nothing emitted, nothing filled.

You either need to tell your code to put some code or data into your .my_test section using __attribute__((__section__(".my_test")) , or simply edit your second example with a LONG again:

.my_test :
{
    . = ALIGN(8);
    KEEP(*(.my_test))
    FILL(0xDEADBEEF)
    . = 0x7FFC;      /* Note shorter to accommodate following LONG */
    LONG(0xBEEFDEAD) /* Deliberately reversed to demonstrate the result */
} > FLASH
answered on Stack Overflow Jan 24, 2020 by John Burger

User contributions licensed under CC BY-SA 3.0