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
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!
-----------------------------------------------------------------------------------------------------------------------
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
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!
-----------------------------------------------------------------------------------------------------------------------
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