• Locked Locked
  • Replies 8 replies
  • Subscribers 55 subscribers
  • Views 4673 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.

CCS build does not recognize "packed" keyword

Guido van Veldhuizen
Intellectual 340 points
Other Parts Discussed in Thread: DM3730
One of my customers is running into problems with building his project using the "packed" keyword in CCS using C/C++ compiler v4.7.
I'm running into a problem with using/building the open-source-based LwIP (Light-weight IP stack) software with our application.  Background info:  in order to generate a CCS build that would run successfully without going into a "data abort" dead-loop, I had to use the "align_structs=4" compiler option.  Unfortunately, this causes a problem with using the LwIP software as this forces alignment of structs on 4-byte boundaries which has the side-effect of introducing "holes" (extra 0-value bytes) into nested structs and the LwIP software uses nested struct definitions for ARP and IP/UDP packets.  The LwIP software does include header files providing an abstraction layer using C/C++ macros for all of its relevant struct definitions but assumes that the compiler provides a "packed" (or equivalent) keyword that can be used to force struct packing.  The spnu151f.pdf (ARM Optimizing C/C++ Compiler v4.7 User's Guide) makes reference to a "packed" keyword that can be used as a Variable or Type attribute (pg 107);  the problem is, I can't seem to get a CCS build to recognize this keyword for all of my attempts so far.  I'm using compiler options "-mv7A8 -g -me --enum_type=packed --align_structs=4 --elf --abi=eabi --code_state=32 --neon --float_support=VFPv3".
Please advice.
  • TI__Guru**** 173310 points

    The --gcc compiler option should be enabled when GCC language extensions (such as packed attribute) support is needed.

  • in reply to AartiG
    Intellectual 340 points
    In addition to the compiler options below I'm now also specifying option "--gcc" and building with the following pre-compiler directives as part of the LwIP abstraction layer:

    #define PACK_STRUCT_BEGIN __attribute__ ((packed))

    #define PACK_STRUCT_STRUCT

    #define PACK_STRUCT_END

    #define PACK_STRUCT_FIELD(x) __attribute__ ((packed, aligned (1))) x

     resulting in the following snippet of build message(s):

    "S:/Projects/JTSI - Phase 1-2 Technology Dev/Software/CodeWarrior/QP/lwip-1.3.1/src/include/ipv4/lwip/ip_addr.h", line 48: warning: invalid attribute for field "addr"

    "S:/Projects/JTSI - Phase 1-2 Technology Dev/Software/CodeWarrior/QP/lwip-1.3.1/src/include/ipv4/lwip/ip_addr.h", line 48: warning: a reduction in alignment without the "packed" attribute is ignored

    "S:/Projects/JTSI - Phase 1-2 Technology Dev/Software/CodeWarrior/QP/lwip-1.3.1/src/include/ipv4/lwip/ip_addr.h", line 64: warning: invalid attribute for field "addrw"

    "S:/Projects/JTSI - Phase 1-2 Technology Dev/Software/CodeWarrior/QP/lwip-1.3.1/src/include/ipv4/lwip/ip_addr.h", line 64: warning: a reduction in alignment without the "packed" attribute is ignored

     for the following ip_addr.h file code snippet:

    PACK_STRUCT_BEGIN

    struct ip_addr {

    PACK_STRUCT_FIELD(u32_t addr);        //This is line 48 referenced in the warning messages above.

    } PACK_STRUCT_STRUCT;

    PACK_STRUCT_END

    The compiler/linker succeeds in building the application seeming to accept the "packed" attribute for the "PACK_STRUCT_BEGIN" directive on the "struct" definition but when I run the application the LwIP software still generates an ARP packet with extra zero bytes between the MAC addresses in the packet ("packed" attribute has no effect).  Interesting how the warning messages indicate a problem using the "aligned" attribute without a "packed" attribute and yet it doesn't do anything with the "packed" attribute when specified.  I'm using CCS version 4.2.4.00033 and the DM3730 uses an ARMv7 microprocessor.

  • in reply to Guido van Veldhuizen
    TI__Expert 4280 points

    The packed attribute is currently only supported for ARM devices that have hardware support for unaligned memory accesses.  I'm not an ARM expert, but I think that basically means the Cortex devices.

    I believe the warning message is issued for the fields that are subject to a packed attribute either because the attribute is applied directly to the field or because it is applied to the containing type.  Thus it did not really accept the attribute in PACK_STRUCT_BEGIN.

    I find it a bit odd that ignoring a packed attribute only issues a warning.  Seems like this would almost always lead to bad news at runtime, so maybe an error is in order.

    PS. An upgrade that will support packed for all ARM devices is under way, but I do not know when it will be released.  Later this year would be my guess.

     

  • in reply to Paul Knueven
    Intellectual 340 points
    Customer would like me to reword the question:
    Does the ARM Cortex-A8 microprocessor in the DM3730 have hardware support for unaligned data access?  The DDI01001 ARM Architecture Reference Manual pages A2-38 thru A2-43 suggests that with the U bit set to 1 and the A bit set to 0 in the system coprocessor (CP15) register 1 (c1), unaligned byte, half-word, and word data access on ARMv6 should work fine without generating any data-aborts.  We're running our application with these bit settings and unless I compile with the "align_structs=4" compiler option we get data-aborts.  The DM3730 data sheet specifies that the ARM Cortex-A8 microprocessor is ARMv7 architecture-based;  is unaligned data access supported on this hardware?
    Please advise.
  • in reply to Guido van Veldhuizen
    TI__Expert 4540 points

    I was not able to reproduce the warning messages reported by the user using the code snippet provided. I was able to compile the struct as a packed struct and achieve an alignment of 1 for the struct. The --align_structs=4 option will override the alignment of 1 for the addr field, which is probably not what the user wants. 

    The user can control whether unaligned accesses can be generated by the compiler by using the --unaligned_access=[on | off] option. The default for all Cortex devices is on. My understanding is that Cortex-A8 does support unaligned accesses, but I do not know if the DM3730 has disabled that capability. If the option is set to off, I believe the compiler will reject the packed attribute. 

    There was a compiler bug, SDSCM00038262, where the compiler would generate unaligned loads and stores using VLDR and VSTR instructions, which do not support unaligned accesses. This was fixed in version 4.7.2 of the compiler. I recommend updating to that release or even better the 4.9.0 release since the 4.7 branch is no longer supported.

  • in reply to Cody Addison
    Prodigy 175 points

    I'm currently using Code Composer Studio with compiler version 4.6.5.  Before I update the compiler I would like to try a build using the --unaligned_access=on option (without the --align_structs option).  How do I specify this option in the project build?  I can't find a predefined compiler option in the C/C++ Build properties nor a way to add this option.

  • in reply to Norman Beyer
    TI__Guru**** 240215 points

    The option --unaligned_access is not supported in the v4.6.5 ARM compiler.

    Thanks and regards,

    -George

  • in reply to AartiG
    Prodigy 30 points

    I come with the same problem, thanks!