| Generated code for object member of variable length structs [message #1763344] |
Fri, 12 May 2017 22:27  |
 James Lockwood
Messages: 43
Registered: July 2009 |
Member |
|
|
Hi,
I have recently run into a compiling issue since updating to the latest ARM GCC compiler (gcc-arm-non-eabi-6-2017-q1-update-win32 from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads).
Apparently this compiler is a little more strict in what it allows.
I have the following .xdc file:
import motion.interfaces.IAxisGroup;
import motion.interfaces.IAxis;
import xdc.runtime.Error;
module AxisGroup inherits IAxisGroup
{
struct SlaveInfo_ {
IAxis.Handle handle_IAxis;
Bool haveAxisControl;
}
const UInt32 Version = 0;
instance:
config IAxis.Handle master_IAxis = null;
config SlaveInfo_ slaveInfo[length] = [];
internal:
Void gearAllSlaveAxes(AxisGroup.Object *obj, Error.Block *eb);
struct Instance_State {
IAxis.Handle master_IAxis;
SlaveInfo_ slaveInfo[length];
Bool abortMotion;
Bool updateMotionParameter;
Bool hasControlOfSlaveAxes;
}
}
It appears that XDCTools generates a struct for variable-length object members in a way that makes that data immutable when it should not be.
The generated code looks like this in the AxisGroup.h:
typedef struct { int length; motion_groups_AxisGroup_SlaveInfo_ const *elem; } __ARRAY1_motion_groups_AxisGroup_Instance_State__slaveInfo;
what I believe should be generated is this:
typedef struct { int length; motion_groups_AxisGroup_SlaveInfo_ * const elem; } __ARRAY1_motion_groups_AxisGroup_Instance_State__slaveInfo;
Notice the difference in the placement of the "const" keyword.
The compiler error I get is "assignment of member 'haveAxisControl' in read-only object"
This error didn't appear when compiling with an older compiler, which I assume is more relaxed in allowing this, or just doesn't check.
As a test, I changed the placement of the 'const' in the AxisGroup.h file, and ran the identical command to compile from a command line window, which was:
C:/Source/GCCARM~1/gcc-arm-none-eabi-6-2017-q1-update-win32/bin/arm-none-eabi-gcc -c -MD -MF package/lib/lib/debug/motion.groups/SourceCode/AxisGroup/AxisGroup.oem4FGCC.dep -x c -Dfar= -D__DYNAMIC_REENT__ -D_DEBUG_=1 -Dxdc_target_name__=M4FGCC -Dxdc_target_types__=trust/targets/gnu/arm/SourceCode/M4FGCC/std.h -Dxdc_bld__profile_debug -Dxdc_bld__vers_1_0_6_3_1 -g -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffunction-sections -fdata-sections -g -Wunused -Wunknown-pragmas -nostartfiles -IC:/Source/GCCARM~1/gcc-arm-none-eabi-6-2017-q1-update-win32/arm-none-eabi/include -I ../../ -I. -IC:/Prj/Portico/Tiva -IC:/Prj/Portico/Bootloader -IC:/Prj/Portico/TrustRepo -IC:/ti/uia_2_00_06_52/packages -IC:/ti/xdctools_3_50_01_12_core/packages -I../.. -o package/lib/lib/debug/motion.groups/SourceCode/AxisGroup/AxisGroup.oem4FGCC SourceCode/AxisGroup/AxisGroup.c
And it compiled just fine.
There are many more modules in packages we have created with variable length arrays in the Instance_State, which fail compiling in the exact same manner.
Switching back to the old compiler is a work-around we can live with for now, but I would like someone to evaluate this and fix if possible.
Thanks.
[edited the command line used to compile to reflect exactly what it was]
[Updated on: Fri, 12 May 2017 22:35] Report message to a moderator |
|
|
|
|
|
| Re: Generated code for object member of variable length structs [message #1763496 is a reply to message #1763348] |
Tue, 16 May 2017 17:46  |
Sasha Slijepcevic
Messages: 115
Registered: July 2009 |
Senior Member |
|
|
James,
we made a change in XDCtools 3.50, described in this bug report - https://bugs.eclipse.org/bugs/show_bug.cgi?id=506855. The fix works for our common usage of vector arrays as a module config parameters, which are immutable at runtime, but it breaks your use case, where a vector array is a member of an instance structure. It also breaks some other users' code, so we are already working on a solution. Unfortunately, there is no a quick workaround that would allow you to keep using XDCtools 3.50. Can you move back to 3.32 or there is something in 3.50 that you definitely need?
Now, for little bit more details:
In 3.32 vector array types were defined as
typedef struct { int length; <ElementType> *elem; } <VectorType>;
The problem there is that we can't force the actual array to be immutable with a const qualifier
const <VectorType> vector;
because constness doesn't propagate to the objects pointed to by the structure members. Only the pointer 'elem' and 'length' are now readonly, but not the underlying array.
So, we changed it to
typedef struct { int length; <ElementType> const * elem } <VectorType>;
and now you can't change the elements in the array which works for our use case, but not for yours.
We don't have a solution yet. We might need two different types that can be used in these two different use cases where the underlying array must stay constant and when it must not.
[Updated on: Tue, 06 June 2017 21:28] Report message to a moderator |
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02943 seconds
] 
Search
Help
Register
Login
Home
