• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 1577 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler: Hack dynamic reloading

Dave Smith62
Intellectual 405 points


Tool/software: TI C/C++ Compiler

Hi,

We look for how to implement runtime loading for embedded targets. Say we modified and then compiled a .c file to .obj, can we quickly reload its content to a running device without relinking the and reloading the entire .out file? The purpose is only for some quick and dirty hack, and we are aware that the symbol files, debugging information and so are not synced, and there might be issues with CCS debugger that the correct symbols/code lines are not found.

1. We know that functions are put in .text sections contiguously. We can deal with this using "CODE_SECTION" directive to allocate large slots for functions that we might "hack" like said above so that reloading will not overwrite other function's space. Also please advise us any better linker directives to this, because with the "CODE_SECTION" way we might need to create many such different SECTION names.

2. Can customer file requests to TI to get at least partial source code of the compiler and linker? We look for some agile hacking to facilitate development just as using Clang/GCC open-source toolchains. TI's ofd xml tool and DSS are good but become restricting when we need deeper functionalities.

3. Still better, as said in (1), is there a way to update the debugging symbol, code lines and so on in this case? We want to operate CCS Debug environment like GNU GDB. Can you advise on how the TI's c/cpp symbols is interfaced to the eclipse CDT? Is that the original CDT release or was modified by TI?

4. As for the object formats Is it ELF/COFF standard conformant or added lots TI's own specifications? By this, I mean there are lots of directives (pragma, pack, CODE_SECTION, etc.) in the TI tool chain. After the chain, is the final .ELF/COFF file any standard conformant, say can it be understood by vanilla CDT tools from www.eclipse.org, or has TI heavily modified the code?

Regards,

Dave

  • 0
    TI__Guru**** 251300 points

    Dave Smith62 said:
    Say we modified and then compiled a .c file to .obj, can we quickly reload its content to a running device without relinking the and reloading the entire .out file?

    The general industry term for this feature is dynamic loading.  TI compiler tools only support dynamic loading for the C6000 device family.  Even then, only if the C6000 system is running Linux.  If your system has an ARM device running Linux, you could consider the dynamic loading features of the ARM GCC compiler.

    Dave Smith62 said:
    Also please advise us any better linker directives to this, because with the "CODE_SECTION" way we might need to create many such different SECTION names.

    Most TI compilers have the build switch --gen_func_subsections, which causes every function to be placed in a section named .text:name_of_function .

    Dave Smith62 said:
    Can customer file requests to TI to get at least partial source code of the compiler and linker?

    The effective answer is no.  The fuller answer ... It is possible to purchase a source code license.  However, this occurs so rarely that we do not have a standard method for handling the transaction.  I have the vague notion it requires lawyers, legal agreements signed by company officers, and large sums of money.

    Dave Smith62 said:
    As for the object formats Is it ELF/COFF standard conformant or added lots TI's own specifications?

    Please see the article A Brief History of TI Object File Formats.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 405 points
    Many thanks!

    What is the loader executable when one "load Program" in CCS? Is it the TI's program or from eclipse?
  • 0 in reply to Dave Smith62
    Intellectual 405 points

    In the name space "com.ti.debug.engine.scripting.Symbol", there are

    void load(java.lang.String sFileName) Load only the symbols from a specified .OUT file onto current target/CPU.

    void loadWithOffset(java.lang.String fileName, long codeStart, long dataStart) Loads the specified program's symbols into the debugger's symbol manager.

    void loadWithRelativeOffset(java.lang.String fileName, long codeOffset, long dataOffset)
    Adds the specified program's symbols into the debugger's symbol manager.

    As in the brief history of TI object files link, the .out format is mostly elf can can be understood by GNU tools. The three java functions above are in DSS help.

    (1) When working with CCS debug GUI, we sometimes noted little quirks in with the symbol manager, for example a global variable variable "var1" might overshadow a local "var1", to name a few, of course these are only debugger symbol problem, not loader/compiler program. If we have access to the symbol manager/debugger code base we can avoid those problems. For both the loader executable, and the symbol manager responsible for "variable" "expression" views, how much of them are from TI or eclipse? If they are eclipse or standard conformant we might fine control them by java/DSS. Are they?

  • 0 in reply to Dave Smith62
    TI__Guru**** 472461 points

    Hi Dave,

    Dave Smith62 said:
    What is the loader executable when one "load Program" in CCS? Is it the TI's program or from eclipse?

    If you are asking about the debugger components that handles the loading of the debug symbols to the debugger and the code to the target, this is all from TI

  • 0 in reply to Dave Smith62
    TI__Guru**** 472461 points

    Dave Smith62 said:

    In the name space "com.ti.debug.engine.scripting.Symbol", there are

    void load(java.lang.String sFileName) Load only the symbols from a specified .OUT file onto current target/CPU.

    void loadWithOffset(java.lang.String fileName, long codeStart, long dataStart) Loads the specified program's symbols into the debugger's symbol manager.

    void loadWithRelativeOffset(java.lang.String fileName, long codeOffset, long dataOffset)
    Adds the specified program's symbols into the debugger's symbol manager.

    Note that these APIs will remove the existing loaded symbols first, and then load the specified symbol. I suspect the APIs for adding symbols is what you are more interested in since you want to add the new symbols to the existing loaded symbols:

    void     add(java.lang.String fileName) Add all of the symbols from the given file to the debugger's symbol manager.
    void     addWithOffset(java.lang.String fileName, long codeStart, long dataStart) Adds the specified program's symbols into the debugger's symbol manager.
    void     addWithRelativeOffset(java.lang.String fileName, long codeOffset, long dataOffset) Adds the specified program's symbols into the debugger's symbol manager.

    However, you would have issue with conflicting symbolic information since the old and new information for the modified c file would still be there. You can't remove the old symbols for just the modified c file since the remove symbol API would remove all the symbols for a loaded file (*.out) instead of just a specified part (but if it was a separate module, then you could use the API to remove the loaded obj). It might be possible to use the hideSection API to hide those symbols.

    Dave Smith62 said:
    For both the loader executable, and the symbol manager responsible for "variable" "expression" views, how much of them are from TI or eclipse? If they are eclipse or standard conformant we might fine control them by java/DSS. Are they?

    The variables/expressions views are from Eclipse. The components that handle the symbol load/management and the actual loading of code to the target is all from TI. But you can certainly use the DSS APIs to load/add/remove/show/hide symbols and load the program to the target

    Thanks

    ki