System_LibcStubs.c Inclusion vs. xmclibcstubs library question

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User5581
Level 3
Level 3
Hi All,
I am updating a DAVE3 project that was started over a year ago in the days of DAVE3.1.6 or so.
I am now using DAVE 3.1.10 with the CMSIS patch of May 2014. In this project, we are now looking
to locate some code and static variables using the __attribute__ ((section (".data3"))) in our C source code.

I want to use the new linker script (.ld file) available now that has the comment /* Template Version 1.2 dated 05 May 2014 */
at the top that is auto-generated for new DAVE3 XMC4500 projects. This linker script defines the .data3 section that we would like to use to locate code and data in PSRAM; The old linker script did not have this section defined. I understand that I have to replace the startup_XMC4500.s file with a new one to match, and I have done this.

If I try to build this project after replacing the .ld file and the startup_XMC4500.s file, then the build errors look like this:

c:/dave-3.1.10/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/lib/armv7e-m\libc.a(lib_a-init.o): In function `__libc_init_array':
init.c:(.text.__libc_init_array+0x40): undefined reference to `_init'
c:/dave-3.1.10/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/lib/armv7e-m\libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
.....


Googling around, it appears the linker can't find a few pieces of libc that it expects. I noticed that the old linker script had the following command near the top:
GROUP(-lxmclibcstubs)
When I add this to the new linker script near the top of the file, then the linker can then build my project and does not report any errors.

However, I notice that if I start a new XMC4500 project in DAVE3 and build it, that there is a file that appears in the project at /Lib/System_LibcStubs.c. It appears to stub out the same missing libc calls that the linker wants.

Apparently, there is an old way and a new way this is handled.

My question is: What is the best way to carry my application forward, and what are the consequences of each of these choices:

  • Leave GROUP(-lxmclibcstubs) in the linker script. (The older way)
  • Copy /Lib/System_LibcStubs.c from a new project to my more mature project, and leave the GROUP(-lxmclibcstubs) command out of the linker script. (The newer way)

I can successfully build using either one, but I do not know if they produce equivalent results. If they are just stub functions (meaning they do nothing but make the linker and calling code happy, but serve no other purpose), then it might not make any difference. Perhaps expectations for the way DAVE3 will handle projects in the future should be a factor in such a decision.

Thanks!
-Kurt
0 Likes
1 Reply
Not applicable
Hi Kurt,

The main reason of existence of newlib stubs is to prevent application code compilation/linking failure when system calls are invoked.
Starting from DAVE 3.1.8, the linking against a pre-compiled stub object is eliminated because of differences in ARM-V7M and ARM-V6M instruction set which led to bus faults on XMC1 devices. Instead the stub file is simply compiled with the correct compiler within a project.
You are advised to copy the LibcStubs file into the project and use updated linker scripts. Future distributions of DAVE 3.1 will not contain the pre-compiled newlib stub library as well.

Best regards,
Sophia
0 Likes