ELF output contains lots of zero data: linker script issue?

It could be that something is going wrong with the linker script. A binary of a small example is almost 7 MB in size:

-rwxrwxr-x 2 user user 6.7M Jun  2 18:13 target/riscv64gc-unknown-none-elf/release/interrupt

Using size, this seems to be allocated to data sections:

$ size target/riscv64gc-unknown-none-elf/release/interrupt
   text    data     bss     dec     hex filename
  38522 6176916   73732 6289170  5ff712 target/riscv64gc-unknown-none-elf/release/interrupt

Digigng further:

$ riscv64-unknown-elf-objdump -x target/riscv64gc-unknown-none-elf/release/interrupt
  4 .bss          00012004  000000008000a000  000000008000a000  0000abf8  2**12
                  ALLOC
  5 .heap         00000000  000000008001c004  000000008001c004  0000abf8  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  6 .stack        005e3ffc  000000008001c004  000000008001c004  0000abf8  2**0
                  CONTENTS, ALLOC, LOAD, DATA

It seems the stack section is in the binary, padded fully with zeros:

riscv64-unknown-elf-objdump --section=.stack -s target/riscv64gc-unknown-none-elf/release/interrupt
Contents of section .stack:
 8001c004 00000000 00000000 00000000 00000000  ................
…
 805ffff4 00000000 00000000 00000000           ............

I'm not sure why this is not treated like the .bss section, implicitly implied to be filled with zeros (the section is correctly labeled NOLOAD, but are not generated with ELF section type SHT_NOBITS).

FWIW this is on K210 and all memory regions are simply aliased to SRAM, sections are not treated any differently there:

MEMORY
{
    SRAM : ORIGIN = 0x80000000, LENGTH = 6M
…
}

REGION_ALIAS("REGION_TEXT", SRAM);
REGION_ALIAS("REGION_RODATA", SRAM);
REGION_ALIAS("REGION_DATA", SRAM);
REGION_ALIAS("REGION_BSS", SRAM);
REGION_ALIAS("REGION_HEAP", SRAM);
REGION_ALIAS("REGION_STACK", SRAM);

To be honest, I'm not good at writing linker scripts and almost sure we can do better. However, I have no idea how to achieve this. The output you see is probably due to the .stack section existence, and I added this section to be able to check for the total stack size like this:

riscv-rt/link.x

Lines 159 to 161 in 2d05df6

    
           ASSERT(SIZEOF(.stack) > (_max_hart_id + 1) * _hart_stack_size, " 
        
           ERROR(riscv-rt): .stack section is too small for allocating stacks for all the harts. 
        
           Consider changing `_max_hart_id` or `_hart_stack_size`.");

Pretty sure that that should work.

I looked into it a bit yesterday (even as far as looking into the lld ELF generation code) and I'm baffled. From everything I saw, (NOLOAD) should be enough to get both no PT_LOAD flag a SHT_NOBITS section, the same combination as .bss. However while PT_LOAD is successfully disabled (so this doesn't actually affect anything),, it is a SHT_PROGBITS section. This combination is sometimes used for metadata and such. But it's obviously not what we want here.

So I'm starting to think it could be some lld issue. But not sure.

Separately from this, we could consider making the section only as big as needed instead of cover all of memory. Make it start AT((_stack_start - _hart_stack_size, * (_max_hart_id + 1)) and be exactly _hart_stack_size, * (_max_hart_id + 1) bytes large.
But I'm not sure that can be expressed.

This seems to be a known (and fixed) issue: rust-lang/rust#73201
Introduced in nightly-2020-05-22 by LLVM update rust-lang/rust#67759, fixed in nightly-2020-06-08 by rust-lang/rust#73072
Present in stable 1.45.0 and 1.45.1, fixed in beta 1.46.0.

Navigation Menu

Repository navigation

ELF output contains lots of zero data: linker script issue? #60

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	ASSERT(SIZEOF(.stack) > (_max_hart_id + 1) * _hart_stack_size, "
	ERROR(riscv-rt): .stack section is too small for allocating stacks for all the harts.
	Consider changing `_max_hart_id` or `_hart_stack_size`.");

ELF output contains lots of zero data: linker script issue? #60

Description

Activity

laanwj commented on Jun 2, 2020

Disasm commented on Jun 3, 2020

laanwj commented on Jun 3, 2020

Disasm commented on Aug 1, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions