- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Tool/software: TI C/C++ Compiler
Hello,
We found very well hidden compiler's bug during testing CGT 8.3.4. Problem manifested on startup, when C++ constructors are called, so it was very hard to detect root cause and find temporary WA, but we managed to prepare local reproduction basing on ASM listings. I'm attaching sample code with class/struct hierarchy required to reproduce issue:
#define SIZE_OF_BIG_STRUCT 10200
#define NUM_OF_BIG_MEMBERS 4
typedef unsigned char u8;
typedef unsigned int u32;
typedef u8 TUsedSizeType_t;
typedef enum
{
EContext1 = 0,
EContext2,
EContext3,
EMaxContexts
} EContextTypes_t;
struct SimpleStructWithConstructor
{
SimpleStructWithConstructor(u32 arg = 9)
{
y = arg;
}
u32 y;
};
template <typename SIZE_TYPE>
struct CommonContextPart
{
SIZE_TYPE own;
SIZE_TYPE nextFreeIndex;
u8 group : 7;
u8 inUse : 1;
};
template <u32 ContextId, typename s_t> struct Context_t { };
template <typename size_type>
struct Context_t <(u32)EContext1, size_type> : public CommonContextPart<size_type>
{
u32 bigArrayToSimulateBigContent[SIZE_OF_BIG_STRUCT];
SimpleStructWithConstructor m_simpleStructWithConstructor;
};
typedef Context_t<(u32)EContext1, TUsedSizeType_t > BigStruct;
struct SmallStruct
{
void init()
{
x = 3;
}
u32 x;
};
struct TestClassCtx
{
TestClassCtx();
BigStruct m_bigMember[NUM_OF_BIG_MEMBERS];
SmallStruct m_smallMember;
};
TestClassCtx::TestClassCtx() : m_bigMember()
{
m_smallMember.init();
}
int main(void)
{
TestClassCtx testVar;
}
In ASM file, please don't focus on "main" function, as it isn't problematic one (in original code we have pools, where placement new is called, so stack usage in "main" is not problem in our software). Instead, we are interested in compiler's generated auxiliary function $P$F0. It isn't affected with CGT7, but with CGT8 stack consumption is horrible huge. Our ASM experts translated affected code into C++ language as something like:
void constructor(int8_t *ptr)
{
int8_t tempSpace[40808];
memset(tempSpace, 0, sizeof(tempSpace));
memcpy(ptr, tempSpace, sizeof(tempSpace);
}
We prepared some findings regarding sample code:
Fix for this bug is extremely important for us, because we are not able to detect such type of problem easily till crash occurrs. We would like to receive correction with RSA intrinsics at the latest.
Best Regards,
ZD
Hello after longer break,
We verified, how this tool could help us in our daily work. Results are promising, but we have also some comments to share with you.
First of all, we still suffer with incomplete call graphs content for - let's say - regular out files. This looks, like I described before, so to remind: we see only some low level calls (I mean our base subsystem) and no calls from "higher-level" components. Due to this, we can't use the method suggested in previous post. However, we managed to get full call graph, when we compiled our project with "-g" option, so this fact is in contrast with description from tutorial (I mean this: ).
Analysis of this output show, that information from call graph is very valuable. We were able to detect easily extremely huge stack usage discussed here and got all function calls leading to this. To have more opinions, we had an opportunity to analyse stack overflow issue from different system component, which has started to manifest recently. Root cause was unknown, because crash was visible only, when unrelated change in code was introduced. Finally, call graph showed, which callpath caused problem and what should we fix (how much stack size could be increased or which part of code requires optimization). So our final opinion is, that this tool can be helpful. Thank you for your suggestions.
When it comes to our comments, we would like to report one strange issue we met in second case. When we tried to use "optimized" version of command for ofd6x (parameters like "-xg --xml_indent=0 --obj_display=none,header,optheader,symbols,battrs --dwarf_display=none,dinfo"), we suffered from segmentation fault issue and we were unable to get xml and call graph. Processed out file was big, approximately 390MB. However, we decided to process it with "-xg" parameters only and after long time (I'm not sure, but it was approximately half an hour) we received xml file of crazy size: over 16.5 GB! This xml file was processed by call graph after 2-3 hours, but output was valuable (all calls were visible). Unfortunately, I'm not allowed to deliver you more details like used out file etc. If it would be helpful, used cgxml tools version is cgxml-2.61.00 (Linux version).
Since increased stack issue can be detected during static analysis now, we are able to do some workarounds to deal with this issue. It's still very important for us to get final correction (and we expect, it will be published with next compiler release), but we're not blocked with further activity now.
BR,
ZD
