• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 966 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: [TMS5703137] Calling convention for static functions

PIOTR ZIELINSKI
Prodigy 30 points

Other Parts Discussed in Thread: TMS5703137

Tool/software: TI C/C++ Compiler

Hi E2E Support Team,

I am compiling software on TMS5703137 device. Currently I am using TI Code generation tools tms470 5.1.6 for Windows (without CCS).

Some of the functions in the software are static. Is it true that TI compiler may make assumptions about the static functions, so that it does not follow ARM EABI? If so, can I change that behavior? I have seen that there is call_assumptions, but it appears to have effect on global symbols.

Is it possible to display somehow using TI tools functions that do not follow EABI method of parameter passing? It appears that DWARF has a calling convention indication like DW_CC_normal, DW_CC_nocall.

Thanks,

Piotr

  • 0
    TI__Guru* 84285 points
    Yes, it is possible that if the TI compiler determines that a particular function cannot be overridden, and cannot be called by a function that expects it to adhere to the calling convention, that it might specialize it, inline it, etc. Obviously this changes the way the function is called. No, there is no user control over this sort of behavior. If you want to foil this optimization, move the static function to another file. To my knowledge, the TI compiler does not use DW_CC_nocall.

    Could you be more specific about what it is you want to do?
  • 0 in reply to Archaeologist
    Prodigy 30 points
    That is unfortunate.

    I am currently involved in developing testing environment for low level software testing. I will not go into much detail, but in my environment all functions are callable. That means that if compiler may generate static functions that do not follow ABI a tester might try to call a static function, and the results will be incorrect (if argument passing is done via unexpected registers).

    Function inline however is not that big of a problem though, since inlined function can be tested in the inlined place.
  • 0 in reply to PIOTR ZIELINSKI
    TI__Guru* 84285 points
    For an extern function X, the compiler will not (cannot) change its calling convention, because there might be some function Y somewhere out there which calls X, perhaps indirectly. For a static function, the compiler can in some cases be sure that it can see all of the callers, it is in theory possible (but very unlikely) that the compiler could alter the static function, perhaps by avoiding unnecessary register save/restore code.

    In brief, if the compiler thinks a function is callable from as yet unseen callers, it will strictly follow the calling convention. Make your functions extern so that the compiler thinks they could be called from as yet unseen callers.
  • 0 in reply to Archaeologist
    Prodigy 30 points
    Thank you for your help, however I cannot change the code. We receive the code from a customer and we test it as is (low level testing).

    It would only help me to identify functions that do not follow the calling convention which cannot be tested directly, or we could ask the customer to build the software with a compiler option forcing strict calling convention.

    If neither solution can be used, then I guess this discussion reached an end. Thank you.
  • 0 in reply to PIOTR ZIELINSKI
    TI__Expert 4930 points

    Your fundamental problem is that you have information that the compiler doesn't:  that any function can be called from outside the program.

    If the program is delivered to you already compiled, then yes, there isn't much you can do except cope with it.

    If it's delivered as source and you compile it, then compiling with -o2 instead of -o3 will avoid many of the possible call changes, because that level of optimisation disables interprocedural analysis and transforms.  For a true brute-force approach, -Dstatic= (ie, defining the symbol "static" to be the empty string) will make all the static functions extern.  Unfortunately, it will also break any static local variables.

    By the way, inlined functions may still be a problem, because they won't have well-defined boundaries once integrated into the caller.  -o2 will avoid automatic inlining but not functions that are declared inline.