• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 988 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

Compiler/TM4C129XNCZAD: TI RTL appears to have nested _lock() calls

Compiler/TM4C129XNCZAD: _register_mutex_api() seems to have no effect

Dave Hohl
Expert 2315 points
Part Number: TM4C129XNCZAD

Tool/software: TI C/C++ Compiler

I used _register_mutex_api() to register the mutex functions the run-time library needs. I stepped into the _register_mutex_api() code to verify that it is actually executing.

However, none of the mutex-related functions that I registered are getting called. And if I single step through printf(), the __TI_file_lock() is just a call to _nop().

After looking through the mutex code, I suspected that perhaps the mutexes are never getting created. So I tried to set a breakpoint in create_resource_mutexes(), but the debugger says there is no executable code associated with any of the source code lines for that function. I double-checked that __TI_RECURSIVE_RESOURCE_MUTEXES is defined for compiling _mutex.c. Is there something else I need to do in order to get the mutex stuff to work?

Regards,

Dave

  • 0
    Expert 2315 points
    Some additional info:

    I tried to set a breakpoint in the __TI_file_lock() function, which should call init_mutexes() via the pthread_once() function. However, the debugger will not let me set a breakpoint anywhere in the _mutex.c file. I noticed that the bulk of the code is in an #else block that should be active if __TI_RECURSIVE_RESOURCE_MUTEXES is defined. So it would appear that for some reason the code did not see that symbol as being defined. Normally the debugger will gray out source lines that did not compile, but none of the lines are grayed out in _mutex.c

    The other file that tests __TI_RECURSIVE_RESOURCE_MUTEXES is _pthread.c. Interestingly, the debugger shows code grayed out in the following block:

    #if !defined(__TI_RECURSIVE_RESOURCE_MUTEXES)
    #define _register_mutex_api(p1,p2,p3,p4,p5)

    #else

    This indicates that _pthread.c is properly seeing the __TI_RECURSIVE_RESOURCE_MUTEXES symbol as being defined.

    Is it possible that even though I have copied _mutex.c into my project, the compiler/linker is still picking it from the library instead of locally?

    Regards,

    Dave
  • 0 in reply to Dave Hohl
    Expert 2315 points
    I changed the

    #if defined(__TI_RECURSIVE_RESOURCE_MUTEXES)

    in _mutex.c to

    #if 1

    and the debugger still won't let me set a breakpoint. So somehow the linker must be pulling in a different version of the object file. But _pthread.c seems to work fine, and I treated the two files identically when I added them to the project.
  • 0 in reply to Dave Hohl
    Expert 2315 points

    I thought perhaps the reason the local copy of _mutex.c was not getting linked in is that none of the functions in it was getting called directly. So I added calls to __TI_file_lock() and __TI_file_unlock right after calling _register_mutex_api(). The code compiled, but I got a linker error saying that the symbol __TI_delete_mutexes_ptr is unresolved. That variable is declared as extern in _mutex.c, with a comment saying that the pointer is maintained in exit.c.

    However, I did a search for __TI_delete_mutexes_ptr in all of the library source code, and there does not seem to be a definition of it anywhere. Any idea why that might be?

    Regards,

    Dave

  • 0 in reply to Dave Hohl
    TI__Guru* 84225 points
    That pointer is supposed to be defined in exit.c; make sure you have it in your list of files. Are you using a custom version of exit.c?

    I feel I need to take a moment to clarify that I haven't tested any of my suggestions; anything I've suggested with regard to the RTS locking mechanisms has just been a quick-and-dirty suggestion when applied to ARM. These locks have been thought out and tested with respect to SYS/BIOS threads on C6000, but not on any other target. We just assume it would work the same, if activated. TI doesn't presently support thread-local storage on ARM, and we don't technically support compiling the ARM libraries with __TI_RECURSIVE_RESOURCE_MUTEXES defined; that is, it should probably work, but we aren't going spend any time documenting it, including on this forum.

    That said... what sort of environment do you have? Are you using some sort of OS that can dispatch proper threads? Are you concerned just with interrupts? That is, what sort of "multi-threading" do you have in your system?
  • 0 in reply to Archaeologist
    Expert 2315 points
    Hi, Archaeologist,

    I am not using a custom version of exit.c. Since I am linking with a TI-provided library, the file being used is presumably the one supplied with the CCS installation. On my PC it is located in:

    C:\ti\ccsv8\tools\compiler\ti-cgt-arm_18.1.1.LTS\lib\src\exit.c

    There is no __TI_delete_mutexes_ptr defined in that file. Since TI does not support the nested mutex feature on this processor, perhaps the exit.c was never updated to include that pointer.

    I am running uC/OS-II (a fully pre-emptive, multi-tasking RTOS) on a Tiva TM4C129X processor, using CCS and the TI ARM compiler. I am working with legacy code written by someone else, so I can't be sure, but I do not think there should be any calls to non-reentrant functions in any interrupt service routines. So I am just concerned about non-interrupt code.

    Doesn't TI have its own RTOS that is available for the ARM? I would have thought there must be some mechanism it uses to provide locking features to the run-time library, but perhaps I am wrong.

    Anyway, since this feature is not supported, I guess I will have to figure out how to use the basic locking functionality to do what I want. Thanks for your willingness to help.

    Regards,

    Dave