rom: requested regions overlap

[LnnrtS]

Description

I am running in the exactly the same bug as described here.
In one version of the linker script it works in qemu and not on the board and in the other version it is the other way around.

Explanation and possible fix described in the last comment

Versions

• qemu 2.8.0-12.1
• Debian Stretch

[ilg-ul]

I would need a way to replicate this, simply reading those comments is not enough to diagnose the problem.

[ilg-ul]

I checked my build configurations, and both use 0x08000000, the F4DISCOVERY has

  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
  RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K

and the F0DISCOVERY has:

  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K
  RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 8K

As far as I can tell, this is the correct setting, and it works both with physical boards and QEMU.

By what is your configuration different?

[LnnrtS]

The main linker script is also relevant as described in this comment; I can also reproduce that here.

this works in qemu

_sidata = LOADADDR(.data);

.data : AT (_sidata)
{
...
} > RAM

this doesn't

.data : ALIGN(4)
{
...
} > RAM AT>FLASH

I haven't digged any deeper than that..

[ilg-ul]

All my projects use:

.data : ALIGN(4)
  {
    FILL(0xFF)

    __data_start__ = . ;           /* Standard newlib definition. */
    __data_begin__ = . ;           /* µOS++ specific */
    *(.data_begin .data_begin.*)   /* µOS++ __data_begin_guard */

    *(.data .data.*)
    *(.gnu.linkonce.d.*)

    *(.sdata .sdata.*)
    *(.gnu.linkonce.s.*)

    *(.data_end .data_end.*)       /* µOS++ __data_end_guard; must be last */        
    . = ALIGN(4);
    __data_end__ = . ;             /* Standard newlib definition. */
  } >RAM AT>FLASH

and this works in both cases.

Probably it is another small detail.

[LnnrtS]

rom: requested regions overlap (rom phdr xpack-dev-tools/qemu#9: [..]application.elf. free=0x0000000008003b1c, addr=0x0000000008003ae0)

The problem is that the LMA of bss seems to collide with the .check_stack section

  0 .isr_vector   000001d8  08000000  08000000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .inits        00000038  080001d8  080001d8  000101d8  2**2
                  CONTENTS, ALLOC, LOAD, CODE
  2 .data         0000043c  20000000  080036a4  00020000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          0000003c  2000043c  08003ae0  0002043c  2**2
                  ALLOC
  4 .text         000033a0  08000210  08000210  00010210  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  5 .ARM.extab    0000000c  080035b0  080035b0  000135b0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .ARM.exidx    000000e8  080035bc  080035bc  000135bc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .noinit       00000000  20000478  20000478  0002043c  2**2
                  CONTENTS
  8 ._check_stack 00000100  20000478  08003ae0  00020478  2**2
                  ALLOC
  9 .stab         0000003c  00000000  00000000  0002043c  2**2
                  CONTENTS, READONLY, DEBUGGING
 10 .stabstr      00000076  00000000  00000000  00020478  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .comment      00000044  00000000  00000000  000204ee  2**0
                  CONTENTS, READONLY
 12 .ARM.attributes 0000002a  00000000  00000000  00020532  2**0
                  CONTENTS, READONLY
 13 .debug_aranges 00000208  00000000  00000000  00020560  2**3
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_info   0000634a  00000000  00000000  00020768  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_abbrev 000013f8  00000000  00000000  00026ab2  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_line   000023f9  00000000  00000000  00027eaa  2**0
                  CONTENTS, READONLY, DEBUGGING
 17 .debug_frame  00000fb0  00000000  00000000  0002a2a4  2**2
                  CONTENTS, READONLY, DEBUGGING
 18 .debug_str    000025a3  00000000  00000000  0002b254  2**0
                  CONTENTS, READONLY, DEBUGGING
 19 .debug_loc    00002a2e  00000000  00000000  0002d7f7  2**0
                  CONTENTS, READONLY, DEBUGGING
 20 .debug_ranges 00000328  00000000  00000000  00030228  2**3
                  CONTENTS, READONLY, DEBUGGING

this is how .check_stack is defined (if I remove that, it also works)

._check_stack : ALIGN(4)
{
    . = . + _Minimum_Stack_Size ;
} > RAM 

The qemu bug is probably that it does not ignore LMA for these sections where they are irrelevant.
Or they should not have set LMA at all..?

[ilg-ul]

QEMU generally expects valid input and behaves strangely in corner/error cases.

If you fix the memory map, does it work?

[LnnrtS]

If I remove .check_stack it works. But it will probably fail again if I add another uninitialized section that has some LMA with it that should actually be ignored.

Maybe there is a way to remove the dummy LMAs but still this is a confirmed bug upstream that also other people ran into with real world use cases.

[ilg-ul]

I use exactly the same mechanism:

  /*
   * It should generate an error if the heap overides the stack.
   */
  .stack __stack - __stack_size :
  {
    PROVIDE( _heap_end = . );      /* Standard newlib definition. */
    PROVIDE( __heap_end__ = . );   /* µOS++ extension. */
    . += __stack_size;
  } >RAM

Maybe there is a way to remove the dummy LMAs but still this is a confirmed bug upstream that also other people ran into with real world use cases.

QEMU is far from perfect, but I still don't get it. You don't have to disable any checks, you simply have to provide non overlapping sections.

If you have concrete proposals how to address this, please let me know.

[LnnrtS]

I suggest to apply the patches mentioned in this qemu bug report

Here are the links to the patches: loader: Handle ELF files with overlapping zero-initialized data
loader: Ignore zero-sized ELF segments

[ilg-ul]

I transferred the issue from qemu-xpack.git to qemu.git, since it is related to QEMU functionality, not the build scripts..

[ilg-ul]

The two patches were applied and v2.8.0-13 released.

@LnnrtS, could you check if these patches solved your issue?

[LnnrtS]

Yes, its fixed. Thanks!

[ilg-ul]

Great, thank you for confirming it.