How force the address of code for libraries (sprintf, memcpy, etc...) ?


I use KPIT GNU RL78 v15.02 with e2studio 3.1 for this project.

I would like to know (if it is possible), the option to force the linker to localise the memory addresses of the libraries, (files liboptm.a, liboptc.a and libgcc.a) to a section "user". By default, it links these files in the ".text" section.

These libraries being common to my bootloader and the firmware, I wish that these 2 codes call the same functions at the same place, (the memory area that I reserved for my bootloader).

I hope my request is clear enough and there is a way to do it?

thank you in advance,


  • Hi Eric,

    What you meant with force or localise is to fix the address of these functions? However, please wait until forum members respond to your concern. Thanks for understanding.

    RenesasRulz Forum Moderator

  • In reply to JB:

    Hi JB,

    I meant I want to create a user section, (".commonsection" for example), in which all libraries , (inside files liboptm.a, liboptc.a and libgcc.a) are placed by linker.

    I know create a section, but I don't know how link the libraries at this section.

    For example I would like an automatic option who writes in file stdio.h:

    "int _EXFUN(sprintf, (char *, const char *, ...)  _ATTRIBUTE ((__format__ (__printf__, 2, 3)), (section(".commonsection"))));"

    Is this option exist for linker or compiler?

    I hope my question is more clear...

    Best Regards,


  • In reply to Eric:


    Let me see if I understand your question.
    You would like to create a section in flash that contains functions common to both your bootloader and your main?
    You would like to have both sections of code call these functions from the same locations in flash memory?

    Is this correct?

    Mike Clements
    RenesasRulz Moderator
  • In reply to Eric:

    Hi Eric,

    Please experiment editing directly the GNU LD's linker script for your GNURL78 project, accordingly to your particular part's needs.

    1. Add the Shared Section on the region definitions


    VEC : ORIGIN = 0x0, LENGTH = 4
    IVEC : ORIGIN = 0x4, LENGTH = 188
    OPT : ORIGIN = 0xC0, LENGTH = 4
    SEC_ID : ORIGIN = 0xC4, LENGTH = 10
    OCDROM : ORIGIN = 0xFE00, LENGTH = 512
    ROM : ORIGIN = 0x000D8, LENGTH = 0x0FF28
    SHARED_ROM : ORIGIN = 0xA000, LENGTH = 0x5E00
    MIRROR : ORIGIN = 0xF2000, LENGTH = 52991
    RAM : ORIGIN = 0xFEF00, LENGTH = 4095

    2. Map all required objects to be on the shared region:

    .commonsection (ORIGIN (SHARED_ROM)) : 
    PROVIDE(_commonsec_start = ORIGIN(SHARED_ROM));
    _commonsec_start = .;
    . = ALIGN(2);
    _commonsec_end = .;
    _commonsec_size = SIZEOF(.commonsection);
    } > ROM
  • In reply to Mike Clements:

    Hello Mike,

    yes it's correct.
    Because I need to optimize the memory.

    Today bootloader and main are seperatly on two projects.

    But new application needs more memory.

    So I want to make a fusion between the two projects.

    A lot of code are same for both, USB, gcc library, etc...

    Best Regards,
  • In reply to Felipe T :

    Hello Felipe,

    thanks you very much for your answer.

    It seems interesting but I don't know how add the lines :





    I use option setting directly on e2studio :


    If I modify directly the file "MyProject_auto.gsi" it seems don't care, the library files are always build in ".text" section...


    Thanks for your help.



  • In reply to Eric:

    with e2Studio linker setting section, I added an object "expression" in my ".gcclibrary_section":

      with path of library files.


    But, when I build my project, the section ".gcclibrary_section" is empty

       (part of map file)

    And library functions keep on generic section ".text":

      (2nd part of map file...)

    Maybe someone can tell me what's wrong?

    Thanks in advance...


  • In reply to Eric:

    Hi Eric,

    e² studio may have changed a lot since 2014 (v.3) hence I am unable to reproduce it exactly under my environment. Besides, the installer is not available anymore on the official download site, otherwise one could mimic your environment on a virtual machine. I've attached the newer linker editor outline picture (for e² studio v6.2.0, to be exact) which may give you some ideas. In e² studio v.6, any project may have full access to the linker_script.ld file (it rests under the src sub-directory) for any newly generated project. Unfortunately I am not entirely familiar with e² studio v.3 series' LD editor GUI's constraints, if there are any, but it may be possible to override it (usually -T <path_to>my_personal_script.ld) somewhere under the linker settings.

    One last advice. I have had to prevent *.(.text.*) from loading during .text processing section, otherwise it wouldn't be placed under the common section later on. Please take a look:

     .text (. + __romdatacopysize): 
    /* *(.text.*) */
    etext = .;
    . = ALIGN(2);
    } > ROM
  • In reply to Eric:

    What if you go the other way, not to change the section of the libraries but change the sections of your boot loader and application code?
    In your functions you can change the sections using the __attribute__ instruction.
    extern void foo (void) __attribute__ ((section ("boot"))); // places function foo in section boot.
  • In reply to FrankL:

    Hello !

    To Felipe,

    Thanks a lot for the clarifications.
    Maybe the solution for me is to migrate my code to e2Studio 6 and the last Renesas GCC compiler?

    It worries me a bit because the initial project actually dates from 2014 ...
    And I use the libraries FSL and Dataflash ...

    But it is true that the LD script editor seems more user-friendly and more complete.
    Do you think migration of the whole can be easy?

    to Frankl,

    thank you for your answer but it is unfortunately not so simple, because the boot must work even if the firmware is missing, or in case of corrupted firmware.
    And the update is done with USB, and display functions that are common to the 2 programs (boot and application), in addition to the libraries ...

    Best Regards
  • In reply to Eric:

    I think this will always cause problems. One possible problem is if application and firmware do not use exactly the same libraries and display/communication functions.
    The linker usually does not add all library functions but only those being used by the generated code. If one application uses less library functions than the other then not all library functions will be linked to the same addresses for both builds, even if the start address is the same.
  • In reply to FrankL:

    Hi Frank,

    yes I am aware of the problems that this method entails. especially for the maintenance of future evolutions.

    At the same time, we are trying to optimize our initial application code.

    Thank you in any case for your advice.

    Best Regards,