ARM.exidx OVERLAP issue

[mjbcswitzerland]

Hi All

When adding a foreign library we now get a linker error due to code overlapping with the reset vector (code linker to start at 0x5080 due to boot loader at 0x0000).

This is the linker error

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/bin/ld.exe: section .ARM loaded at [00005080,00005087] overlaps section .vectors loaded at [00005080,00005087]

and this is the map file showing that libgcc.a is locating something there:

.ARM.exidx      0x00005080        0x8
 .ARM.exidx     0x00005080        0x8 c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/armv6-m\libgcc.a(_divdi3.o)
 .ARM.exidx     0x00005088        0x0 c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/armv6-m\libgcc.a(_udivdi3.o)
                                  0x8 (size before relaxing)

According to various sources this has something to do with stack-unwinding debug support but various suggestions as to how it may be disabled have not had any effect.

In the linker script file there is a section:

      .ARM.extab   : { *(.ARM.extab* .gnu.linkonce.armextab.*) } >FLASH
       .ARM : {
       __exidx_start = .;
         *(.ARM.exidx*)
         __exidx_end = .;
       } >FLASH

but the result is the same with or without this. It looks to be correctly telling the linker to put whatever this is into the flash:

MEMORY
{
    FLASH (rx) : ORIGIN = 0x00005080, LENGTH = 0x00040000-0x5080
    SRAM (wx)  : ORIGIN = 0x1fffe0c0, LENGTH = 0x00008000-0xc0
}

but why on earth is it overlapping with other things in this single case?

Anyone know anything about this and how to get rid of it....?

Regards

Mark

[ZhangJennie]

hi,

From my understanding,you want to merge another app in your project but overlap with current code in same memory address. correct?

I this case, I suggest you read this document, maybe it can help you

https://community.nxp.com/docs/DOC-328202 

Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mjbcswitzerland]

Hi

No, this has nothing to do with merging two application - just linking in a library.

In the meantime I have maybe been able to force the section to not overlap with other addresses by doing

  __ARM_start__ = ALIGN(__data_load_end__ , 4);
  .ARM.exidx ALIGN(__data_load_end__ , 4) :
  {
    __exidx_start = .;
    *(.ARM.exidx* .gnu.linkonce.armexidx.*)
    __exidx_end = .;
  }
  __ARM_end__ = __exidx_start + SIZEOF(.ARM.exidx);

but the linked library is not yet operating correctly (but likely to be due to its use of malloc())..

Regards

Mark

[ZhangJennie]

to link a library to a project, go to C/C++ Build > Settings > Cross ARM C++ Linker > Libraries and specify the precompiled library to be used and its path.

for example

the library .a or .lib file doesn't include address information, after linking it to project, the linker will allocate range of memory address to library code.

if you still have overlap error with above setting, So I wonder your library defines some constant variable in the exact address?

Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mjbcswitzerland]

Hi

The problem is not that the foreign library can't be added or that the foreign library has code that has fixed addresses. It is that the library in question uses other library calls in the standard librariy (libggc.a) which make reference to something in this area (reading up on the area it is said to have something to do with stack unwinding of C++ exceptions or for debugging).

I don't know why the section is being located to overlap with other sections by the linker since I also can not believe that library code is trying to force a specific location in memory.

I'm still hoping that the workaround to explicity tell the linker to put the area after others will prove to be suitable....

Regards

Mark