Link problem with rdimon.specs

[danielsexton]

Hi,

I have just started with KDS, wanted to move to an environment with a  debugger.

I imported a program from MBED and followed the instructions in the tutorial videos to get ready for using the debugger with semihosting.

I found that my program linked & built if I had the other linker flags set to  -specs=nosys.specs, but when I have them set to -specs=rdimon.specs it will not generate an .elf. There are messages like:

"..\\mbed\\TARGET_K64F\\TOOLCHAIN_GCC_ARM\\system_MK64F12.o" "..\\mbed\\TARGET_K64F\\TOOLCHAIN_GCC_ARM\\startup_MK64F12.o" "..\\mbed\\TARGET_K64F\\TOOLCHAIN_GCC_ARM\\board.o" "..\\mbed\\TARGET_K64F\\TOOLCHAIN_GCC_ARM\\cmsis_nvic.o" "..\\mbed\\TARGET_K64F\\TOOLCHAIN_GCC_ARM\\retarget.o" -lmbed

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/softfp\librdimon_s.a(rdimon-syscalls.o): In function `_read':

syscalls.c:(.text._read+0x0): multiple definition of `_read'

..\mbed\TARGET_K64F\TOOLCHAIN_GCC_ARM\retarget.o:retarget.cpp:(.text._read+0x0): first defined here

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/softfp\librdimon_s.a(rdimon-syscalls.o): In function `_lseek':

syscalls.c:(.text._lseek+0x0): multiple definition of `_lseek'

..\mbed\TARGET_K64F\TOOLCHAIN_GCC_ARM\retarget.o:retarget.cpp:(.text._lseek+0x0): first defined here

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/softfp\librdimon_s.a(rdimon-syscalls.o): In function `_write':

syscalls.c:(.text._write+0x0): multiple definition of `_write'

..\mbed\TARGET_K64F\TOOLCHAIN_GCC_ARM\retarget.o:retarget.cpp:(.text._write+0x0): first defined here

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/softfp\librdimon_s.a(rdimon-syscalls.o): In function `_close':

syscalls.c:(.text._close+0x0): multiple definition of `_close'

..\mbed\TARGET_K64F\TOOLCHAIN_GCC_ARM\retarget.o:retarget.cpp:(.text._close+0x0): first defined here

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/softfp\librdimon_s.a(rdimon-syscalls.o): In function `_sbrk':

syscalls.c:(.text._sbrk+0x0): multiple definition of `_sbrk'

..\mbed\TARGET_K64F\TOOLCHAIN_GCC_ARM\retarget.o:retarget.cpp:(.text._sbrk+0x0): first defined here

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/softfp\librdimon_s.a(rdimon-syscalls.o): In function `_open':

syscalls.c:(.text._open+0x0): multiple definition of `_open'

..\mbed\TARGET_K64F\TOOLCHAIN_GCC_ARM\retarget.o:retarget.cpp:(.text._open+0x0): first defined here

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/softfp\librdimon_s.a(rdimon-syscalls.o): In function `_isatty':

syscalls.c:(.text._isatty+0x0): multiple definition of `_isatty'

..\mbed\TARGET_K64F\TOOLCHAIN_GCC_ARM\retarget.o:retarget.cpp:(.text._isatty+0x0): first defined here

collect2.exe: error: ld returned 1 exit status

I have not tried to run the debugger yet but feel because of the way my program operates I will need the semihosting mode.

Any thoughts.

[mobilewill]

I ran into the same issue with exporting mbed into embitz. I thought I had a solution since mbed has a semihost library but it seems that is for the original mbed boards. Too bad, there is a define in device.h #define DEVICE_SEMIHOST. But I had no luck.

The good news is you can use

Serial pc(SERIAL_TX, SERIAL_RX);

pc.printf("test");

Then use something like realterm to monitor the output. So far it seems you can leave the serial open during flashing and debugging. So its kinda of works the same as semihost. Maybe one day this will work correctly. I wish I could spend more time on but I need to move on with this project. Just need to decide now to go semi-bare metal or use mbed libraries to save time.

Also a FYI I also had to change the order of the libraries to even compile at all at first. mbed has to be before c. That way you can still use libc later on if you need it.

Edit: It seems no matter what semi doesn't work. I forced it to include the semihost_api.h but no go. But I noticed that you don't even need to include Serial pc and you can just use straight printf but you have to fflush(stdout); afterwards for it to actually work. The output is viewable via the serial port with real term. Doesn't interfere with debugging at all.

[danielsexton]

I want to bump this question - hopefully someone else has been through this before.

[BlackNight]

Hi Daniel,

It seems that your files from mbed already include all the low level I/O function calls, therefore you get 'multiple definitions'.

So in that case, can you add -specs=nosys.specs to the linker option? That way the library low level I/O functions won't be included.

I hope this helps,

Erich

PS: Semihosting for Kinetis Design Studio V3.0.0 and GNU ARM Embedded (launchpad) | MCU on Eclipse

[danielsexton]

Thanks Erich,

That is indeed the problem however when I compile with specs=nosys.specs linker option I can build and go into the debug mode but I don't get the Semi-hosting functionality, i.e. I do not see the serial port output in the console window.

I am not quite sure how to go about resolving these conflicts.

[BlackNight]

Hi Daniel,

then I would think that the mbed code does not properly do the semihosting.

I recommend that you use the normal libraries. At least I can say that the normal approach worked for me.

Erich

[danielsexton]

I wish it were that simple, since I am relying on functions that come with embed I am not sure I can just change out the whole thing as I have a deadline to meet. I can likely just use an alternate port on my board as my serial port and use that until I get things tested. That is if there is no other solution out there.