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.

Question on Defect SDSCM00038327 in TI ARM Compiler version 5.1.7

I am looking through the defect list for TI ARM Compiler version 5.1.7.

I came across known issue SDSCM00038327 and am not sure I understand the impact.

Could someone please better explain this defect to me, and if there is anything I might need to do to work around it.  What impact does it have to me when I'm using the RTS?

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00038327
-------------------------------------------------------------------------------

Summary : ARM RTS libraries expose enumerations across ABI
boundaries, but are marked as having no visible
enumerations
Affected Component : Runtime Support Libraries (RTS)

Description:
The ARM RTS libraries are marked as having no visible enumerations. This is
true for the C library routines, but not the C++. Some C++ header files
include inline functions that manipulate enumeration values. Possible
solutions:

1. Quit marking libraries as having no visible enums. This is bad because then
we will have to provide libraries with both enum types.
2. Get rid of the enumerations.
3. Force enumerations exposed in header files to be either packed or int.
Packed can be done using the packed gcc attribute. The trouble is that for
ARM, gcc attributes are not available without the --gcc switch. I believe
C6x exposes attributes by default, so we can probably make the switch for
ARM (and maybe all targets). Forcing enums to be int can be done by
including a dummy enumerator in every enumeration that is INT_MAX.

  • SDSCM00038327 can only be triggered if you attempt to mix object files with different settings of the --enum_type option. The RTS libraries shipped with the compiler are compiled with --enum_type=packed. The C features shipped in the RTS library do not expose any enum types in the ABI, so you'll only be affected if you use certain C++ features, such as iostream. In summary, you can only be affected if you compile any object file with --enum_type=int and include a C++ header file.

  • Thank you, that is a helpful response.

    It looks like by default the compiler compiles an object file the "--enum_type=unpacked" option unless you specify otherwise. Is it okay to mix "packed" and "unpacked" or should I be using "-enum_type=packed" for my compilation as well?
  • I'm sorry, I assumed you were using EABI. For EABI, the RTS is built with –enum_type=packed for EABI, but for COFF it is built with –enum_type=unpacked. You cannot mix any of these settings, so if you are compiling for COFF, you should use --enum_type=unpacked, or don't use the option at all.
  • Hello, I believe I am using EABI. I was referring to the TI ARM Compiler Manual for 5.1 of the TI ARM compiler. According to the TI ARM compiler manual for version 5.1, "-enum_type=unpacked" is the default compiler setting (if you don't specify anything for -enum_type).

    I am specifically compiling with RTS “rtsv7M4_T_le_v4SPD16_eabi.lib”. This can be found in "compiler\arm_5.1.7\lib".

    According to "compiler\arm_5.1.7\lib\mklib.c" the following options were used to compile rtsv7M4_T_le_v4SPD16_eabi.lib.
    { "THUMB_MODE",
    "FPV4SPD16",
    "AEABI_THUMB_MODE",
    "SETJMP_MEMSET_T2_ASM",
    "AEABI",
    "PERFCRIT_1_T2_ASM",
    "THUMB2_MODE",
    "EABI",
    "_T2_NON_AEABI",
    "AEABI_UNALIGNED_T2_ASM",
    "V7M4",
    "VFP",
    "AEABI_VFP_WRAPPERS",
    "AEABI_NFE_T2_ASM",
    "LITTLE_ENDIAN",
    "THUMB_ONLY",
    "THUMB2",
    "THUMB2_ONLY",
    "PERFCRIT_2_T2_ASM",
    "ANYABI_T2_ASM",
    "COFF_OR_THUMB_ONLY",
    "AEABI_T2_ASM" }
  • That's incorrect.  The default value of --enum_type changes depending on whether you are using EABI or COFFABI.

    For EABI, the default is --enum_type=packed

    For ti_arm9_abi, the default is --enum_type=unpacked

    If you are linking against rtsv7M4_T_le_v4SPD16_eabi.lib, you are definitely using EABI.  That library uses --enum_type=packed.

    The expected use case is that you should not use --enum_type at all.  Let the compiler use the default setting, and use the RTS libraries shipped with the compiler.  All of your object files will be consistent, and you will not suffer from SDSCM00038237.