• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 57 subscribers
  • Views 1847 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.

Error due to incompatible enumeration type for xdc target

yihe
Guru 67180 points


Hi,
I am running Cotext M3 with BIOS 6.21.00.13, XDC:3.15.04.70.
In ELF format by default enum is "packed",  But I want to have them as 32 bit. So I use the cc options:
M3.ccOpts.suffix += " --enum_type=int "; everthing thing is fine until trying to link, Please see the following error.
Could someone help to solve this?
Regards,
Yihe

fatal error: object files have incompatible enumeration types ("C:\Program
   Files\Texas
   Instruments\xdctools_3_15_04_70\packages\ti\targets\arm\rtsarm\lib\ti.target
   s.arm.rtsarm.aem3<HeapStd.oem3>" = packed,
   "package/cfg/Debug/grpxDisplay_xem3.oem3" = 32-bit)
gmake[1]: *** [Debug/grpxDisplay.xem3] Error 1

  • 0
    TI__Mastermind 37985 points

    Yihe,
    when you specified "--enum_type=int" you changed that property for your code. But, all other libraries you are building with (BIOS libraries, XDC runtime packages) are built with enums packed. The linker cannot combined object files with different enum sizes.

    To solve your problem, there has to be a new Cortex M3 XDC target with int-sized enums. Then BIOS and the XDC runtime package must be rebuilt with that new target. I don't think BIOS 6.21 is delivered with sources, which means that even if you created your new target, you still can't rebuild BIOS 6.21 on your own. You need the BIOS team to support that new target. In case you want to try to create a new XDC target, here are some instructions:

    http://rtsc.eclipse.org/docs-tip/Creating_Targets#Inheriting_from_an_Existing_Target

     

  • 0 in reply to Sasha Slijepcevic
    TI__Guru 67180 points

    Thanks for the reply. That was too bad, do you know whom I should contact to ask to support this new target?

    Yihe

  • 0 in reply to yihe
    TI__Mastermind 20805 points

    There's a potential workaround for this problem that I just learned about last week!

    If you have enums that require full integer width (for datacom or some other app where you put enums into a structure I presume), you can update your enum definitions to have an additional field.  And set that additional field to "INT_MAX".   Your code will never use this new field, but  this will force the entire enum to be int-sized.  I'd like to know if this workaround is OK for you. 

    The new 6x ELF compiler has similar switch to override the default enum (which is short).  It is really painful (in build time, test time, and disk space) to provide duplicate  libraries for both enum=short and enum=int. 

    I'm hoping that TI can recommend using the short enum (default) and ask that people use the above workaround for cases where they must have int-sized enums.  If this won't work, we'll be faced with double the libraries and additional testing, etc.

    -Karl-

  • 0
    TI__Expert 4280 points

    Another possibility...

    Using the --gcc option to enable GNU C extensions including allowing "attributes" to be placed on types you can use the "unpacked" attribute on an enumerated type definition to override the default packed representation for that type.

       typedef enum { A1, B1 } enum8;                             /* represented in 8 bits in EABI (ELF) mode */
       typedef enum { A2, B2 } __attribute__((unpacked)) enum32;  /* represented in 32 bits even in EABI mode */

    It is up to the user to ensure that ALL users of a type like enum32 see identical definitions (that is, they all better agree with respect to being packed or unpacked) the linker will not check for consistency.

  • 0 in reply to Paul Knueven
    TI__Guru 67180 points

    Thanks for all your help. we keep our enum definition, just make it as int type instead of "instantiating" the filed as enum in the structure.

    Regards,

    yihe

     

  • 0 in reply to yihe
    TI__Expert 3925 points

    Hi,

     

    The other option is to keep the last dummy enum number as 0xFFFFFFFF, this way compiler will always keep 4 bytes for variable of enum type.

     

    Thanks,

    Brijesh Jadav