Problems with arrays in namespaces

[scotty]

Hello Freemaster developers!

After we have moved some array variables into namespaces, they seem not work anymore. Particularly, the first array element is displayed correctly, the following elements not. (Only a ? is displayed.)

Originally we noticed this with an older version (3.1.2.4). But I also tried the latest version (3.2.0.5). The behavior is the same.

Can anyone confirm this behavior? Is this issue already known? 

Best regards,
michaeL

[scotty]

Hello Michal,

Thank you for your prompt response! - We only see the question mark ('?') after we have put some arrays, which are located in a structure, into namespaces. The first array member is always displayed correctly, but the following not.

For example, it looks like this:

We found out that we can workaround this issue by adding the byte offset manually to the beginning of the array.
If we write instead of Rtesl::Dmx::BigStructure.MyArrayNamePwm[1] the expression Rtesl::Dmx::BigStructure.MyArrayNamePwm[0]+1, the address is evaluated correctly and the value is displayed instead of a question mark.
Before BigStructure.MyArrayNamePwm was not in a (nested) namespace and the values were always correctly displayed, if we simply wrote BigStructure.MyArrayNamePwm[1], BigStructure.MyArrayNamePwm[2] ...

There was no question mark, if there were no namespaces.
So, this seems not to be a protection issue on the controller side.

Are you sure that Freemaster can calculate the addresses of array members (in structures) in namespaces correctly? We use a GCC based toolchain and a binary ELF file as input for Freemaster. 
I appreciate further help!

Best regards,
michaeL

[MichalH]

Hello,

well, it is possible that the FreeMASTER ELF parser is not able to evaluate the array element address correctly. You should see the calculated address directly in the Variable definition dialog, like in this picture:

Can you compare the calculated addresses of elements [1], [2], etc. using the working and not-working versions of ELF files?

Also, you can dump the ELF symbol list by clicking the "View" in the Project Options dialog:

You can compare the dumps, especially with respect to the size of the problematic array elements. The element size is taken into account when evaluating array indices [1], [2], ... etc.

Please tell us how do the problematic symbols differ.

Thanks,
Michal

[scotty]

Hi Michal,

Thanks again for your reply. Until now, I did not know about the "View" button and its function.

However, I could reproduce this issue with some sample code:

I generated two array variables and added them to the project.

As you can see, the array in the namespace is not displayed properly. Most of the time the wrong value (7) is displayed for the array members > 0. But sometimes also the question mark is displayed. The correct information is displayed in the array which is in the common namespace.

The related information in the text file which is generated by the View button looks like this:

calcPrimeNumbers 0x202c4ebc 40
calcPrimeNumbers[0] 0x202c4ebc 4

_ZN4Calc12primeNumbersE 0x202c468c 40

Calc::primeNumbers 0x202c468c 40
Calc::primeNumbers[0] 0x202c468c 4

primePoolIndex 0x202c4ee4 4

Can you confirm this issue?

Regards,
michaeL

[scotty]

Addendum:

I opened the ELF file with Ozone by Segger to check the array properties. If I move the mouse over the arrays, the displayed information looks all right.

The array in the common/global namespace:

The array in the namespace called Calc:

In Freemaster V3.2.0.5 we use the "Binary ELF with DWARF2/DWARF4 dbg format" to parse the symbols from the toolchain output.

The information for the array in the global namespace is OK for all members.

calcPrimeNumbers[1] = calcPrimeNumbers + 1*sizeof(uint32_t)
0x202C4EC0 = 0x202C4EBC + 4

For  Calc::primeNumbers[1] the address is not shown (compare screenshot in previous post).

[scotty]

Until the issue is fixed in the next Freemaster version, I patched the project file in XML representation as a workaround. With the help of a regular expression the search can be easily described.

I searched for

<member name="address" type="string">(.*::.*)\[([1-9]\d*)\]</member>

and replaced it by:

<member name="address" type="string">$1+$2*sizeof\($1[0]\)</member>

This only matches arrays in namespaces whose index is greater than zero.

I tried it with Notepad++ V8.4.4:

And it works fine.

[MichalH]

Hello MichaeL/@scotty 

thank you for your extra work on repeating the issue. It seems the symbolic parser in FreeMASTER is correct, but the [] operator processing gives incorrect results. We will try to address this issue asap.

Please share the test ELF file with us.

Thank you,
Michal

[scotty]

Hello Michal,

Thank you for your analysis and for prioritizing this issue.

The example code with the prime numbers was added to our (confidential) production application. Do you really need this huge ELF file for further analysis? It is much bigger than the allowed 25MB which can be attached here. It would take some effort for me to isolate this code to a minimum viable example.

I strongly assume that you have some test application where you can easily add an array within a namespace. I attached my test code which can easily moved to such an application.

Or do you think this is an issue of the size or complexity of the ELF file?

So, if arrays within namespace work fine in your test application, I only would provide the original ELF file (on a web storage) or an ELF file to a simplified application.

That's why I initially asked if you or anybody can confirm this issue...

Best regards
michaeL

PS: Since cpp files are not allowed to be attached in this forum, I zipped the source code.

[MichalH · Accepted solution]

Hello @scotty,

thanks again. The issue is confirmed and fixed. The colon character in the symbol name has been confusing the array element access operator [] so the final address could not be calculated at all. This was the reason why a numeric address information disappeared in the variable dialog and why reading of the variable always failed.

It will take a few days for me to create a patch and publish it here via the community. If you need an immediate test version, reach out to me directly at michal.hanak@nxp.com.

Thank you for your cooperation,
Michal

[scotty]

Thank you, Michal, for your effort and prompt response. Great to hear, that you could track down and fix the bug. We are looking forward to the new version.

I will also contact you by e-Mail...

Best regards,
michaeL

[MichalH]

Hello,

do you mean a questionmark '?' is displayed in the FreeMASTER Variable Watch view? This might be caused by TSA safety - the target MCU application may deny an access to memory which is not described by any TSA entry. 

You can disable this protection (set FMSTR_TSA_SAFETY to 0) or completely disable the TSA (FMSTR_USE_TSA to 0) and use just an ELF file to load application symbols.

Or you can try to extend the TSA table entry for the array directly in the target application. The TSA macros (FMSTR_TSA_RO_VAR etc) use the sizeof() operator internally so make sure this code can detect the real size of the array instance.

Or do you see the questionmark anywhere else?

Thanks,
Michal