• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 509 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.

Original question:

TMS570LS1114: tiarmlang: warning: object files have incompatible wchar_t types

TMS570LS3137: tiarmclang no_stm and short-wchar options

Sergey pl
Intellectual 355 points

Part Number: TMS570LS3137

Hello,

We have a project that uses a third-party precompiled library. The library has been compiled with TI ARM CGT toolchain with --no_stm and --wchar_t=16 options and used rtsv7R4_T_be_v3D16_eabi.lib as Runtime library.

Now We are testing migration from CGT to TI ARM Clang compiler (1.3.0 LTS).  We enable -fshort-wchar option to provide cmpartibility with the third-party library, but then we observe the following issues:

  1. The linker cannot find  no_stm_memcpy and no_stm_memset functions
  2. The linker provides a serios of warnings like
    warning: object files have incompatible wchar_t types ("vector.cpp.obj in C:\ti\arm_clang_1_3_0_lts\lib\armv7reb-ti-none-eabihf/c++/libc++.a" =   --wchar_t=32, ".\build/src/debug.o" = --wchar_t=16)

As a solution to the first problem I provided the old rtsv7R4_T_be_v3D16_eabi.lib as an additional library input to the linker. It found the missing functions, but I don't feel that it is the correct way to provide them.

So my questions are:

  • Is there a workaround to enable no_stm option on CLANG compiler?
  • Is there a way to tell the compiler to use the the RTS libraries with --wchar_t=16 instead of --wchar_t=32?
  • As an option, how bad would it be to use rtsv7R4_T_be_v3D16_eabi.lib instead of standrad RTS libraries of the Clang compilers? If that is acceptable, how can we tell the linker not to use internal RTS libraries? Iэму tried --disable_auto_rts option, but it does not change the Linker output (it still adds the intrinsic RTS libraries like below, as I can see with -v option)
     
    -I<install directory>/lib
--start-group -llibc++.a -llibc++abi.a -llibc.a -llibsys.a \
              -llibsysbm.a -llibclang_rt.builtins.a \
              -llibclang_rt.profile.a --end-group
  • 0
    TI__Guru**** 253590 points
    Sergey pl said:
    Is there a workaround to enable no_stm option on CLANG compiler?

    The TI proprietary compiler armcl option --no_stm avoids a silicon problem on certain Arm devices.  It is not supported in tiarmclang.  If you use such a device, then you need to build with armcl.  If you do not use such a device, then you can continue to use this library.  It will work.  But because it avoids STM instructions, the functions in this library may take a few more cycles.  

    Sergey pl said:
    Is there a way to tell the compiler to use the the RTS libraries with --wchar_t=16 instead of --wchar_t=32?

    Unfortunately, no.  The RTS libraries supplied with tiarmclang presume wchar_t is 32-bits.

    Sergey pl said:
    how bad would it be to use rtsv7R4_T_be_v3D16_eabi.lib instead of standrad RTS libraries of the Clang compilers?

    It wouldn't work.  The linker presumes you use the RTS libraries supplied with the compiler.

    Note this linker diagnostic ...

    Sergey pl said:
    warning: object files have incompatible wchar_t types ("vector.cpp.obj in C:\ti\arm_clang_1_3_0_lts\lib\armv7reb-ti-none-eabihf/c++/libc++.a" =   --wchar_t=32, ".\build/src/debug.o" = --wchar_t=16)

    ... is a warning.  If your code never uses the type wchar_t, then you can ignore the warning.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Guru 92251 points
    George Mock said:
    The TI proprietary compiler armcl option --no_stm avoids a silicon problem on certain Arm devices. 

    Is the silicon problem DEVICE#B064 "Incorrect Write to External Memory using Store-Multiple (STMxx) CPU instruction"?

    DEVICE#B064 is present in TMS570LS31x/21x Silicon Revision C, and was fixed going from silicon revision C to silicon revision D.

  • 0 in reply to George Mock
    Intellectual 355 points
    George Mock said:
    The TI proprietary compiler armcl option --no_stm avoids a silicon problem on certain Arm devices.  It is not supported in tiarmclang.  If you use such a device, then you need to build with armcl.  If you do not use such a device, then you can continue to use this library.  It will work.  But because it avoids STM instructions, the functions in this library may take a few more cycles.  

    The problem is that regardless of the exact device that we use, we have to use a precompiled library which cals no_stm_memcpy and no_stm_memset. And these functions definetely are part of armcl RTS library.
    Another option to solve this problem would be to redefine these two functions in the applcation code. Is it possible to find anywhere how they are implemented?

  • +1 in reply to Sergey pl
    TI__Guru**** 253590 points
    Sergey pl said:
    The problem is that regardless of the exact device that we use, we have to use a precompiled library which cals no_stm_memcpy and no_stm_memset.

    I apologize for overlooking that.  Please consider using the tiarmclang linker to change those symbols so that the standard memcpy and memset functions are called instead.  These are the linker options ...

    --symbol_map=no_stm_memcpy=memcpy
    --symbol_map=no_stm_memset=memset

    If you use those linker options directly from an invocation of tiarmclang, then prefix them with -Wl,.  For example ...

    -Wl,--symbol_map=no_stm_memcpy=memcpy
    -Wl,--symbol_map=no_stm_memset=memset

    Chester Gillon said:
    Is the silicon problem DEVICE#B064 "Incorrect Write to External Memory using Store-Multiple (STMxx) CPU instruction"?

    Yes.  The details can be found in this silicon errata document.  If you have any questions about it, I'll have to refer you to the device experts.

    Thanks and regards,

    -George