Problem: undefined reference to ‘__end__’ if using Semihosting

Posted on by

In case you are running into the following GNU linker error about a missing __end__:

'Building target: MyProject.elf'
'Invoking: Cross ARM C++ Linker'
...
toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv6-m/rdimon-crt0.o: In function `_start':
(.text+0xdc): undefined reference to `__end__'
collect2.exe: error: ld returned 1 exit status
make: *** [MyProject.elf] Error 1
Failed link because missing __end__

Failed link because missing __end__

The GNU linker complains that rdimon-crt0.o needs the symbol __end__.  This symbol marks the end of the user data/RAM section, and is needed by the rdimon library specs which is used with semihosting.

Common .specs GNU linker used with the GNU ARM Embedded (launchpad) linker are:

  • -specs=nosys.specs is used for disabling semihosting in the project, using ‘dummy’ file I/O and std I/O handlers.
  • -specs=rdimon.specs is used for semihosting support.

💡 See “Semihosting for Kinetis Design Studio V3.0.0 and GNU ARM Embedded (launchpad)“.

That necessary __end__. symbol needed by rdimon-crt0.o can be added to the linker .ld file like below. The __end__ needs to mark the end of the user (initialized) user RAM:

  ._user_heap_stack :
  {
    . = ALIGN(4);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    PROVIDE ( __end__ = . ); 
    __heap_addr = .;
    __HeapBase = .;
    . = . + __heap_size;
    __HeapLimit = .;
    . = . + __stack_size;
    . = ALIGN(4);
  } > m_data

💡 In case your linker file has that missing __end__ problem, and you are generating the linker file with Processor Expert, make sure that after you change you disable the linker file generation. See last screenshot in “Disable my code generation“

As of today, projects created in Kinetis Design Studio v3.0.0 for Processor Expert are lacking that __end__ symbol in the generated linker file. This is not an issue as long I do not enable semihosting. I have submitted a support ticket, so I expect this could be fixed in the next update. Until then, hopefully the above workaround helps.

Happy Ending 🙂

PS: thanks to Mark M. for providing details on that issue!

11 thoughts on “Problem: undefined reference to ‘__end__’ if using Semihosting”

  2. The patch worked, but I found the source of the problem to begin with. In the Processor Expert Cpu component, if the Heap size is set to 0 (default) it will not generate the line
    PROVIDE ( __end__ = . );
    I set the Heap size to 0x0C00 like Erich mentioned in an older 2014 article on semihosting and PE generated the extra line, so you don’t have to disable autogeneration.

    Like

    Reply ↓

  3. Hi Erich,
    Tried to use semihosting with FRDM-K22F, bare metal with Processor Expert.
    I get the __end__ in the linker file. I also changed the linker to as per your article on semi-hosting with KDS 3.0.
    Problem is that I get compile errors:

    makefile:54: recipe for target ‘FRDM-K22-Semi_Host.elf’ failed
    make: *** [FRDM-K22-Semi_Host.elf] Error 1

    Problem seems to be in the the make file below.

    Any guesses?

    # Tool invocations
    FRDM-K22-Semi_Host.elf: $(OBJS) $(USER_OBJS)
    @echo ‘Building target: $@’
    @echo ‘Invoking: Cross ARM C++ Linker’
    arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -specs=nosys.specs -specs=nano.specs -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -g3 -T “C:/Users/brad/Dropbox/KDS/FRDM-K22-Semi_Host/Project_Settings/Linker_Files/ProcessorExpert.ld” -Xlinker –gc-sections -L”C:/Users/brad/Dropbox/KDS/FRDM-K22-Semi_Host/Project_Settings/Linker_Files” -Wl,-Map,”FRDM-K22-Semi_Host.map” –specs=nano.specs -specs=rdimon.specs -o “FRDM-K22-Semi_Host.elf” $(OBJS) $(USER_OBJS) $(LIBS)
    @echo ‘Finished building target: $@’
    @echo ‘ ‘

    Like

    Reply ↓

  4. That fixed it. I had to leave the “Other Linker Flags” field blank. It was a bit confusing.

    I’m surprised that the ARM debuggers are so limited. For a while, I was using uVision and the uLink Pro. This gives you real time data displays in the debugger with no modification needed to your program. Fantastic setup and it simply works. But it’s really expensive, so I’ll have to make due with KDS/Xpresso/AtmelStudio/Atollic/GNU.

    Alas, I am unable to do real-time data viewing with a Segger J-Trace. I can’t get the RTT to function at all. The GCC interface code fails with _write_r (re-entrant). I may be missing a header file, but it’s not included in the package. I’ll give the Processor Expert RTT module a try.

    P&E Multilink claims it’s possible to view real-time data, but I can’t install the correct plug-in into KDS 3.2.0. (http://www.pemicro.com/blog/index.cfm?post_id=125)

    The SWI and SWO signals are supposed to allow for real-time updates. It’s just too bad it’s not well implemented.

    Like you, I hate using printf (too much like Arduino!). But I can at least see data whilst it’s running.

    Thanks for the help,
    Cheers,
    Brad

    Like

    Reply ↓

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.