Linker errors in two projects

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Linker errors in two projects

    I'm using HEW to target code for the Renesas RX platform. I started a C++ project from scratch and, I think, set up most of the build environment correctly. I realize that my question is more of a tools question than an OS question, but I think this forum is the place where I'm likely to get the best answer.

    I've reduced the compile/link errors I'm getting to two:

    Phase Linker starting
    C:\Code\OS\Segger_embOS\GNURX\LIB\libosLDP.a(OS_StackInfo.o): In function `OS_GetSysStackBase':
    (.text+0x2): undefined reference to `ram_start'
    C:\Code\OS\Segger_embOS\GNURX\LIB\libosLDP.a(OS_StackInfo.o): In function `OS_GetSysStackSize':
    (.text+0xf): undefined reference to `ram_start'
    Phase Linker finished


    In a project targeting the RX platform, and using the GNU RX toolchain, where is ram_start defined?



    I have a second project; it's the same code but targets the HEW compiler. Though I believe my build environments between the two projects are the same, there's still something wrong. When I compile my HEW project, the linker gives me:

    L2310 (E) Undefined external symbol "_OS_CreateTaskEx_R" referenced in "C:\Code\MyProject_HEWRX\Debug\debugtask.obj"
    L2310 (E) Undefined external symbol "_OS_CreateTaskEx_R" referenced in "C:\Code\MyProject_HEWRX\Debug\guitask.obj"


    What did I fail to include in my build environment that is causing this linker error?

    As a newcomer to embOS, and even to C programming in an embedded environment, I appreciate any help the community can offer.
  • I found that to resolve the undefined reference to ram_start, I had to go to the build menu, toolchain, Link/Library tab, Sections category, show entries for Sections, and add a .ram_start section with a _ram_start label.

    I did this by comparing a C project that worked against my C++ project that wouldn't link.

    I am not at all confident that I selected an appropriate start address for _ram_start. While this is, again, a tools issue more than an OS issue, if anyone has any pointers for me on how to ensure that my linker sections are configured properly for the GNU RX compiler, I'd appreciate it. Meanwhile, I'll see if I can't find any documentation on this.

    I am also curious to know why libosLDP requires ram_start when linked with the GNU toolchain, but not when linked with the RX toolchain. There appears to be no definition (though I may be wrong) for ram_start in the project settings for my RX toolchain version of this project.

    Any explanation would be appreciated.
  • Hello,

    please have a look in the embOS cpu/compiler specific manuals, I believe that most of your question are answered there.

    In a project targeting the RX platform, and using the GNU RX toolchain, where is ram_start defined?

    This label is set in the linker section settings.

    L2310 (E) Undefined external symbol "_OS_CreateTaskEx_R" referenced in "C:\Code\MyProject_HEWRX\Debug\debugtask.obj"
    L2310 (E) Undefined external symbol "_OS_CreateTaskEx_R" referenced in "C:\Code\MyProject_HEWRX\Debug\guitask.obj"

    You have to set the library mode for the embOS library you want to use, e.g. if you want to use the *dp..a library you have to set the define "OS_LIBMODE_DP". You could
    also just set the define "DEBUG" which sets also in OS_Config.h the define "OS_LIBMODE_DP".

    I am also curious to know why libosLDP requires ram_start when linked with the GNU toolchain, but not when linked with the RX toolchain. There appears to be no definition (though I may be wrong) for ram_start in the project settings for my RX toolchain version of this project.

    We need this label only in GNU toolchain not in Renesas RX toolchain. We use this label to get the stack sizes for our embOS stack check. With RX toolchain we use predefined labels.

    Maybe it is easier for you to start with a embOS start project. You can also use C++ there.

    Best regards,
    Til
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.