MSP432E401Y: How to isolate the cause of Warning: Type #10457-D Use of variable-length arrays is not thread-safe.

Paul Hooper

Part Number: MSP432E401Y

We have a large program which at link time produces the dreaded #10457-D warning.

I have studied the following threads

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/883790/compiler-msp432e401y-warning-type-10457-d-use-of-variable-length-arrays-is-not-thread-safe/3284696?tisearch=e2e-sitesearch&keymatch=VLA%2520warning#3284696

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1097747/tm4c1290ncpdt-is-there-a-way-to-enable-a-more-descriptive-output-for-10457-d-use-of-variable-length-arrays-is-not-thread-safe/4067136?tisearch=e2e-sitesearch&keymatch=VLA%20warning#4067136

In one of these threads, it is stated

"If your program really uses both VLA and multiple threads, please understand that combination is not supported. The most we can do is detect that combination and issue the warning."

Why can't the compiler/linker provide some details about what is being detected? Is there something that we can look for in the various build artifacts, map file, etc that could provide us some clues? Is there some option we can provide to the compiler to list all of the VLAs it thinks that it encounters?

I attempted to isolate the causes of these warnings by stripping away code and libraries until the warning goes away, and then bring pieces back in (and those pieces and sub-pieces often need to be modified to further isolate code). The build times are slow, and our project is large all of which together results in a very arduous exercise. I got pretty far into it, but had to abandon the effort due to higher priority tasks that I was pulled into. I dread going back to it, especially since it has been a while.

Any ideas about how to more quickly isolate the causes of this warning will be much appreciated.

My memory is fuzzy, but I recall being able to isolate one cause of the warning, and it had to do with something like

char a[some_size]; where some_size was somethng like extern const uint16_t some_size;

This seems like a false positive, as a const is not variable. I ran an experiment where I removed the "extern", and just put something like

const uint16_t some_size = 30;

and the VLA warning went away. For a moment, I had my hopes up that this might be the sole source of the linker warning, but as soon as i brought in more code, the warning reappeared.

So now I am wondering how much of what is being detected as VLA is even real.

We are using the TI v20.2.1.LTS version of the compiler which according to the above related threads is not supposed to produce false positives.

over 1 year ago

0 George Mock over 1 year ago

TI__Guru**** 235315 points

Paul Hooper said:
Any ideas about how to more quickly isolate the causes of this warning will be much appreciated.

I'm sure there are a few different ways to do it. This suggestion is what I would try first.

Whenever a VLA (variable length array) is seen, the code generated by the compiler calls an RTS function named __vla_alloc. This suggestion keys on that.

When you build, use the compiler option --src_interlist. This causes the compiler to not delete the auto-generated assembly file. This file has the same name as the source file, with the extension changed to .asm. It also has comments in it which make it easier to understand.

Suppose you are on a Windows system, and it is convenient to collect all the assembly files into one directory. Then you could run a command like this ...

C:\examples>findstr vla_alloc *.asm | findstr BL
vla.asm:        BL        __vla_alloc           ; [] |6|

The findstr command search those files for the string vla_alloc. The second findstr command filters that output for the BL instruction. The BL instruction is how a function call is implemented. In this simple example, there is only one hit. The file is named vla.asm, which means the corresponding C file is named vla.c. The 6 at the end of the line means the variable length array occurs on line 6 of vla.c.

Suppose you are on a Unix-like system. It is not convenient to collect all the assembly files in one directory. But there is one directory that is at the root of the source code. Then you could run a command like this ...

$ find . -name '*.asm' | xargs fgrep vla_alloc | fgrep BL
./vla.asm:        BL        __vla_alloc           ; [] |6|

It is beyond the scope of a forum post to discuss the details of commands like find, xargs, and fgrep. Internet search for those details. At a high level, this command finds all the assembly files starting at the current directory, searches them for the string vla_alloc, then filters that down to lines that also have BL. The output is similar to that described in the previous example.

At this point, I hope you get the general idea. There are probably other tweaks you can add to make this more practical.

Thanks and regards,

-George

0 Paul Hooper over 1 year ago in reply to George Mock

Intellectual 525 points

Thank you George. I much appreciate your response. As soon as I have a chance to try out your suggestion, I will post back and let you know how it goes.

0 Paul Hooper 11 months ago in reply to Paul Hooper

Intellectual 525 points

Hello George. I finally was able to get to this. I was on vacation last week. I followed your instructions above, and did not come across any occurrences of vla_alloc in the .asm files. Does this mean that the #10457-D warning is a false alarm?

0 Jim Whitehouse 11 months ago in reply to Paul Hooper

Expert 1431 points

I found the same! I noticed that vla_alloc was mentioned in my map file, so it does seem to be in use somewhere. I wondered if some library function is using it somewhere.

0 George Mock 11 months ago in reply to Paul Hooper

TI__Guru**** 235315 points

Paul Hooper said:
I followed your instructions above, and did not come across any occurrences of vla_alloc in the .asm files.

Thank you.

Paul Hooper said:
Does this mean that the #10457-D warning is a false alarm?

I'm not sure. Please take one more diagnostic step. Add this option to the link: --emit_references:file=refs. This creates a file named refs.txt. Please attach it to your next post. Search it for vla_alloc. You should see an entry similar to this one.

Section .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi.lib<vla_alloc.c.obj>:
      
    Section size: 332

    Defines:
      Symbol Name  Offset  TYPE      Scope   Size
      -----------  ------  ----      -----   ----
      __vla_alloc  0       function  global  328 

    Input references:
      Section        from symbol       to symbol    at offset
      -------        -----------       ---------    ---------
      .text:vla.obj  read_and_process  __vla_alloc  16

This entry is from a toy test case I put together that explicitly uses a VLA. Focus on the last line. That says a symbol (a function) named read_and_process, from the input section .text in the object file vla.obj, makes a reference (a call) to the symbol __vla_alloc. I'm interested to see what refers to __vla_alloc in your case.

Thanks and regards,

-George

0 Paul Hooper 11 months ago in reply to George Mock

Intellectual 525 points

Thank you George. It takes forever to generate the refs file. It was linking for at least two hours, and I had to stop it, because I needed to do other things with the system. I will let it run overnight, and hopefully it will complete. I think it is working (as the file is being generated), but just taking a long time.

0 Jim Whitehouse 11 months ago in reply to George Mock

Expert 1431 points

Hi George,

I've also tried your suggestion (yes Paul, it's very slow mine took about 5 hours to finish).

This is what I got:

Section .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi.lib<vla_alloc.c.obj>:

Section size: 332

Defines:
Symbol Name Offset TYPE Scope Size
----------- ------ ---- ----- ----
__vla_alloc 0 function global 328

Input references:
Section from symbol to symbol at offset
------- ----------- --------- ---------
.text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcl:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long) const __vla_alloc 52
.text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcl:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long) const __vla_alloc 104
.text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcx:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long long) const __vla_alloc 60
.text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcx:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long long) const __vla_alloc 114
.text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcm:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long) const __vla_alloc 52
.text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcm:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long) const __vla_alloc 104
.text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcy:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long long) const __vla_alloc 54
.text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcy:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long long) const __vla_alloc 108
.text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwl:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long) const __vla_alloc 52
.text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwl:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long) const __vla_alloc 104
.text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwx:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long long) const __vla_alloc 60
.text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwx:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long long) const __vla_alloc 114
.text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwm:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long) const __vla_alloc 52
.text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwm:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long) const __vla_alloc 104
.text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwy:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long long) const __vla_alloc 54
.text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwy:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long long) const __vla_alloc 108

Any suggestions?

Thanks

Jim

0 George Mock 11 months ago in reply to Jim Whitehouse

TI__Guru**** 235315 points

Thank you for working through this difficult diagnostic step. I didn't realize it would be such a pain.

Well, it is not a false positive. Those functions really do use VLA. The compiler RTS source code is part of the compiler installation. It is located in a directory similar to

C:\ti\ccs1200\ccs\tools\compiler\ti-cgt-arm_20.2.1.LTS\lib\src

The files that use VLA are in the sub-directory libcxx. This code comes from the file locale, which is included by locale.cpp.

template <class _CharT, class _OutputIterator>
_OutputIterator
num_put<_CharT, _OutputIterator>::do_put(iter_type __s, ios_base& __iob,
                                         char_type __fl, long __v) const
{
    // Stage 1 - Get number in narrow char
    char __fmt[6] = {'%', 0};
    const char* __len = "l";
    this->__format_int(__fmt+1, __len, true, __iob.flags());
    const unsigned __nbuf = (numeric_limits<long>::digits / 3)
                          + ((numeric_limits<long>::digits % 3) != 0)
                          + ((__iob.flags() & ios_base::showbase) != 0)
                          + 2;
    char __nar[__nbuf];  // VLA 
    int __nc = __libcpp_snprintf_l(__nar, sizeof(__nar), _LIBCPP_GET_C_LOCALE, __fmt, __v);
    char* __ne = __nar + __nc;
    char* __np = this->__identify_padding(__nar, __ne, __iob);
    // Stage 2 - Widen __nar while adding thousands separators
    char_type __o[2*(__nbuf-1) - 1];  // VLA
    char_type* __op;  // pad here
    char_type* __oe;  // end of output
    this->__widen_and_group_int(__nar, __np, __ne, __o, __op, __oe, __iob.getloc());
    // [__o, __oe) contains thousands_sep'd wide number
    // Stage 3 & 4
    return __pad_and_output(__s, __o, __op, __oe, __iob, __fl);
}

I add the 2 comments // VLA . That does not appear in the original. A similar pattern occurs in other variants of the function do_put. These template functions are instantiated for char and wchar_t types. That's why you see it so many times in the references file.

It is likely your code never calls these functions. Because of the known issue EXT_EP-10871, they are part of your program anyway. If that is the case, then you can ignore the linker diagnostic 10457.

Thanks and regards,

-George

0 Paul Hooper 11 months ago in reply to George Mock

Intellectual 525 points

Hello George:

I am back finally. It took between nine and ten hours to generate the references file. When I looked at the content of the generated file, it gave me some ideas about where to focus my attention. I thought that I might be able to nail down the root cause, and I did to some extent, but I don't know if I ever would have traced some of it to the locale libcxx code you described to Jim.

I tried to distill the problem to a small project that I can easily share. I have a VLATest project that I have put together that demonstrates at least some of the warnings that we are seeing, if not all of them. I can send it to you if it will help. The use of the open source fmt code causes the VLA warning to appear. Here are the lines containing vla_alloc from the refs file.

Line 1: __vla_alloc 0 function global 328
Line 5: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcl:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long) const __vla_alloc 52
Line 6: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcl:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long) const __vla_alloc 104
Line 7: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcx:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long long) const __vla_alloc 60
Line 8: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcx:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long long) const __vla_alloc 114
Line 9: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcm:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long) const __vla_alloc 52
Line 10: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcm:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long) const __vla_alloc 104
Line 11: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcy:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long long) const __vla_alloc 54
Line 12: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcy:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long long) const __vla_alloc 108
Line 13: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwl:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long) const __vla_alloc 52
Line 14: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwl:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long) const __vla_alloc 104
Line 15: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwx:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long long) const __vla_alloc 60
Line 16: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwx:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long long) const __vla_alloc 114
Line 17: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwm:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long) const __vla_alloc 52
Line 18: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwm:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long) const __vla_alloc 104
Line 19: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwy:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long long) const __vla_alloc 54
Line 20: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwy:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long long) const __vla_alloc 108
new 3 (19 hits)
Line 1: Section .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi.lib<vla_alloc.c.obj>:
Line 8: __vla_alloc 0 function global 328
Line 13: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcl:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long) const __vla_alloc 52
Line 14: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcl:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long) const __vla_alloc 104
Line 15: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcx:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long long) const __vla_alloc 60
Line 16: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcx:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long long) const __vla_alloc 114
Line 17: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcm:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long) const __vla_alloc 52
Line 18: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcm:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long) const __vla_alloc 104
Line 19: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcy:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long long) const __vla_alloc 54
Line 20: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcy:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long long) const __vla_alloc 108
Line 21: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwl:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long) const __vla_alloc 52
Line 22: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwl:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long) const __vla_alloc 104
Line 23: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwx:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long long) const __vla_alloc 60
Line 24: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwx:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long long) const __vla_alloc 114
Line 25: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwm:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long) const __vla_alloc 52
Line 26: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwm:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long) const __vla_alloc 104
Line 27: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwy:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long long) const __vla_alloc 54
Line 28: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwy:rtsv7M4_T_le_v4SPD16_eabi.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long long) const __vla_alloc 108
D:\Proteus\Git\GitLab\OS\TI-RTOS\VLAWarning\Workspace\VLATest\Release\refsWithVLAWarn.txt (79 hits)
Line 1985: .text:__vla_dealloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_dealloc free 66
Line 1986: .text:__vla_dealloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_dealloc free 86
Line 2007: .text:_ZN33_INTERNAL_11_vla_alloc_c_be8bd49b21free_dead_allocationsEPv:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> free 80
Line 2008: .text:_ZN33_INTERNAL_11_vla_alloc_c_be8bd49b21free_dead_allocationsEPv:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> free 96
Line 4869: .ARM.exidx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __aeabi_unwind_cpp_pr0 0
Line 4870: .ARM.exidx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __aeabi_unwind_cpp_pr0 0
Line 4871: .ARM.exidx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __aeabi_unwind_cpp_pr0 0
Line 5043: .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_alloc malloc 46
Line 5044: .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_alloc malloc 68
Line 5045: .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_alloc malloc 256
Line 5046: .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_alloc malloc 302
Line 5362: .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_alloc __abort_execution 14
Line 5363: .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_alloc __abort_execution 206
Line 5364: .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_alloc __abort_execution 312
Line 49118: Section .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj>:
Line 49125: __vla_alloc 0 function global 328
Line 49130: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcl:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long) const __vla_alloc 52
Line 49131: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcl:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long) const __vla_alloc 104
Line 49132: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long long) const __vla_alloc 58
Line 49133: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, long long) const __vla_alloc 112
Line 49134: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcm:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long) const __vla_alloc 52
Line 49135: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcm:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long) const __vla_alloc 104
Line 49136: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcy:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long long) const __vla_alloc 54
Line 49137: .text:_ZNKSt3__27num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcy:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<char, std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>>::do_put(std::__2::ostreambuf_iterator<char, std::__2::char_traits<char>>, std::__2::ios_base &, char, unsigned long long) const __vla_alloc 108
Line 49138: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwl:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long) const __vla_alloc 52
Line 49139: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwl:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long) const __vla_alloc 104
Line 49140: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long long) const __vla_alloc 58
Line 49141: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, long long) const __vla_alloc 112
Line 49142: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwm:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long) const __vla_alloc 52
Line 49143: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwm:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long) const __vla_alloc 104
Line 49144: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwy:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long long) const __vla_alloc 54
Line 49145: .text:_ZNKSt3__27num_putIwNS_19ostreambuf_iteratorIwNS_11char_traitsIwEEEEE6do_putES4_RNS_8ios_baseEwy:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<locale.cpp.obj> std::__2::num_put<wchar_t, std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>>::do_put(std::__2::ostreambuf_iterator<wchar_t, std::__2::char_traits<wchar_t>>, std::__2::ios_base &, wchar_t, unsigned long long) const __vla_alloc 108
Line 49146: .ARM.exidx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_alloc 0
Line 49266: Section .text:__vla_dealloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj>:
Line 49294: .ARM.exidx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_dealloc 0
Line 56985: Section .text:_ZN33_INTERNAL_11_vla_alloc_c_be8bd49b21free_dead_allocationsEPv:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj>:
Line 56994: .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_alloc _ZN33_INTERNAL_11_vla_alloc_c_be8bd49b21free_dead_allocationsEPv 156
Line 56995: .ARM.exidx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> _ZN33_INTERNAL_11_vla_alloc_c_be8bd49b21free_dead_allocationsEPv 0
Line 57010: .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_alloc realloc 194
Line 57016: Section .data:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj>:
Line 57028: .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_alloc curr_vla_pool 328
Line 57029: .text:__vla_dealloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> __vla_dealloc curr_vla_pool 108
Line 57030: .text:_ZN33_INTERNAL_11_vla_alloc_c_be8bd49b21free_dead_allocationsEPv:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj> curr_vla_pool 116
Line 57033: Section .ARM.exidx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj>:
Line 57042: .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj>
Line 57138: Section .ARM.exidx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj>:
Line 57147: .text:__vla_dealloc:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj>
Line 60669: Section .ARM.exidx:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj>:
Line 60678: .text:_ZN33_INTERNAL_11_vla_alloc_c_be8bd49b21free_dead_allocationsEPv:rtsv7M4_T_le_v4SPD16_eabi_eh.lib<vla_alloc.c.obj>

You will notice that there are the vla_allocs associated with locale as in Jim's case, but there are other lines that contain vla_alloc, and I would like to understand what causes those to be generated, and whether we should be concerned about them.

In the VLATest project, I have also illustrated the false-positive (at least I believe it is) that I mentioned earlier concerning the use of an extern const variable. Could you confirm that this is indeed a false positive?

I think that it would have been good for TI to document the libcxx issue with respect to the 10457 warning. That could have been very helpful for anyone trying to understand the warning. Now, with this thread, it is documented :).

0 George Mock 11 months ago in reply to Paul Hooper

TI__Guru**** 235315 points

Paul Hooper said:
It took between nine and ten hours to generate the references file.

Ouch! Thank you!

Paul Hooper said:
but there are other lines that contain vla_alloc, and I would like to understand what causes those to be generated, and whether we should be concerned about them.

No. Look back at my post from July 10, where I describe the content of the references file. I am only interested in whatever references the function __vla_alloc. That part of the file begins with a line similar to ...

Section .text:__vla_alloc:rtsv7M4_T_le_v4SPD16_eabi.lib<vla_alloc.c.obj>:

Other lines in the file that happen to contain the string vla_alloc are not relevant. For instance, the object file vla_alloc.c.obj contains yet other functions, none of which are of concern here.

Paul Hooper said:
In the VLATest project, I have also illustrated the false-positive (at least I believe it is) that I mentioned earlier concerning the use of an extern const variable. Could you confirm that this is indeed a false positive?

I cannot confirm it, because I don't have the project. Please follow the directions in the article Sharing projects to zip up the project, then attach the zip to your next post.

Thanks and regards,

-George

0 Paul Hooper 11 months ago in reply to George Mock

Intellectual 525 points

VLATest.zip

Hello George:

I think that I am close to fully understanding. I did read your post carefully before, but I wasn't completely sure. I will try another angle which perhaps I should have tried in the first place. Are we only concerned about entries where vla_alloc is under "to symbol", and vla_alloc appearing anywhere else can be ignored with respect to the VLA warning?

I have attached the project that I referred to in the last post. I tried attaching it last time, but it didn't work using Insert image/video/file. After reading the link you sent, I remembered that all I had to do was drag the archive into the window.

In the attached, you will find the generated refs files (refsWithoutVLAWarn.txt and refsWithVLAWarn.txt) at Workspace/VLATest/Release. refsWithVLAWarn.txt is generated by building the project with MAKE_VLA_WARNING_FMT defined in main.cpp.

In main.cpp, I have also illustrated the false-positive (at least I believe that it is or should be) that I mentioned earlier concerning the use of an extern const variable. It is demonstrated by defining MAKE_VLA_WARNING_EXTERN_CONST. I am interesting in knowing whether this is indeed a false positive?

0 George Mock 11 months ago in reply to Paul Hooper

TI__Guru**** 235315 points

Paul Hooper said:
Are we only concerned about entries where vla_alloc is under "to symbol", and vla_alloc appearing anywhere else can be ignored with respect to the VLA warning?

Yes.

Paul Hooper said:
I have attached the project that I referred to in the last post.

Thank you. I'm sorry I didn't get a chance to complete looking through it today. I'll get back to you tomorrow.

Thanks and regards,

-George

0 George Mock 11 months ago in reply to George Mock

TI__Guru**** 235315 points

Paul Hooper said:
In the attached, you will find the generated refs files (refsWithoutVLAWarn.txt and refsWithVLAWarn.txt) at Workspace/VLATest/Release. refsWithVLAWarn.txt is generated by building the project with MAKE_VLA_WARNING_FMT defined in main.cpp.

The build with MAKE_VLA_WARNING_FMT somehow references the locale related functions. Among those functions is do_put, which I have already shown uses VLA.

Paul Hooper said:
In main.cpp, I have also illustrated the false-positive (at least I believe that it is or should be) that I mentioned earlier concerning the use of an extern const variable.

A simpler demonstration of this problem is ...

extern const int array_size;

void do_work(int *);

void example()
{
   int array[array_size];  // VLA
   do_work(array);
}

Because the value of array_size is not known at compile time, array ends up being a VLA.

Thanks and regards,

-George

0 Paul Hooper 11 months ago in reply to George Mock

Intellectual 525 points

Thank you George.

George Mock said:
Because the value of array_size is not known at compile time, array ends up being a VLA.

It seems to me that the warning should then be given at compile time, and not by the linker which would greatly facilitate isolating the source of the warning.

George Mock said:
The build with MAKE_VLA_WARNING_FMT somehow references the locale related functions. Among those functions is do_put, which I have already shown uses VLA.

Is there some way to override the linkage of individual functions within a library such as the do_put?

From the VLA related thread referenced at the beginning of this thread

"The problem is that the VLA implementation code uses a couple of global variables to track VLAs, and if two threads do VLA things, those globals can be corrupted and crash the program."

Is it possible to know more detail about how these two global variables track VLAs?

I'll be out of the office for the remainder of the week.

0 George Mock 11 months ago in reply to Paul Hooper

TI__Guru**** 235315 points

Is practical for you to change over to the new TI Arm Clang Compiler? The implementation of VLA is much better. It always allocates memory from the function local stack frame. Even when the amount of memory is not known at compile time. This implementation avoids all of these issues.

Paul Hooper said:
Is there some way to override the linkage of individual functions within a library such as the do_put?

Unfortunately, no.

Paul Hooper said:
Is it possible to know more detail about how these two global variables track VLAs?

The documentation does not get into those kinds of details. But the compiler installation does include the source code to the RTS library. It is located in a directory with a path similar to:

C:\ti\ccs1200\ccs\tools\compiler\ti-cgt-arm_20.2.1.LTS\lib\src

Inspect the files vla_alloc.c and vla_alloc.h, and see how they use global variables.

Thanks and regards,

-George

0 Paul Hooper 11 months ago in reply to George Mock

Intellectual 525 points

Thank you George. I am back from a few days off. One follow-up question.

George Mock said:
Is practical for you to change over to the new TI Arm Clang Compiler? The implementation of VLA is much better.

What is the "new TI Arm Clang Compiler"? I thought that is what we are using. We are not using GCC.

0 George Mock 11 months ago in reply to Paul Hooper

TI__Guru**** 235315 points

TI releases two different Arm compilers. They are both described here. For short, I call the legacy TI Arm® C/C++ Compiler Tools armcl, and the newer TI Arm® Clang Compiler Tools tiarmclang. Those are the names of the compiler shell commands used when invoking each compiler.

In the first post you say ...

Paul Hooper said:
We are using the TI v20.2.1.LTS version of the compiler

Only armcl has a release with that version number, thus I conclude you use armcl, and not tiarmclang.

My earlier question still stands. VLA is better supported by tiarmclang. Is it practical for you to change to it?

Thanks and regards,

-George

0 Paul Hooper 11 months ago in reply to George Mock

Intellectual 525 points

I was not aware of the two different TI Arm compilers until you mentioned it in this thread. After reading the link that you provided, it appears that the newer Clang compiler became available sometime after v20.2.x.LTS was released. Is that correct? If not, when did the newer compiler become available?

Is it practical for us to change to using the new Clang compiler?

Maybe. It depends on what is involved in the change. Can we just switch in the new compiler with minimal updates to our project files, or is it more complex than that? What would be involved in changing to using the newer compiler?

If we are able to make the change, it appears that there would be many benefits. Are there any drawbacks to making the change?

0 George Mock 11 months ago in reply to Paul Hooper

TI__Guru**** 235315 points

Please watch the video titled Compatibility with armcl from the tiarmclang video series.

Thanks and regards,

-George

0 Paul Hooper 11 months ago in reply to George Mock

Intellectual 525 points

Thank you. I will try switching to use the new compiler and see exactly what is involved. I'll let you know how it goes.

0 George Mock 11 months ago in reply to Paul Hooper

TI__Guru**** 235315 points

Consider migrating a small project first. Create a small and simple project that builds with armcl. The smaller the better. Then migrate that to tiarmclang. Then scale up from there to your big project. I suspect this method is easier than going for the big project from the start.

Thanks and regards,

-George

0 Paul Hooper 11 months ago in reply to George Mock

Intellectual 525 points

I thought that I would start with the one that I attached earlier in this thread. That is a pretty simple project. I was hoping that it would convert easily, but ran into obstacles. I am not finding much help online. The closest I got was the following link.
e2e.ti.com/.../cc3235modasf-migration-to-clang, I realize that in the link you referred me to, that there is a detailed guide to mapping compiler options, etc, but that is not the same as having a working example that is structured similarly to our projects.

It would be nice if there was a project example similar to the tcpecho project provided with the MSP432 Simplelink SDK that was setup to build right out of the box with the TI ARM CLang compiler. Our projects are structured in a similar manner where there is a project dedicated to the TIRTOS configuration. Could you point me to such a sample project which will build sucessfully with the newer compiler, and if not would you be able to convert the tcpecho project so that it will build and run successfully with the newer TI ARM CLang compiler? Having such an example project would be most helpful.

Also, from another thread, I learned that the LTS version of the new compiler does not support exception handling. It looks like if we required exception handling, we would need to use the STS version. Could you confirm that? If that is indeed the case, do you have an idea when exception handling would be available in the LTS version?

0 George Mock 11 months ago in reply to Paul Hooper

TI__Guru**** 235315 points

I'm not familiar with the MSP432 SimpleLink SDK. Generally speaking, an SDK documents which compiler(s) it is tested with. You should use one of those compilers. If tiarmclang is not among those compilers, then it isn't practical for you to change to it. I'm sorry I didn't think to mention this before.

Regarding C++ exception handling ... Support for it is introduced in version 3.0.0.STS. It is not currently supported in any LTS release. An LTS release that supports it is planned for 4Q this year.

Thanks and regards,

-George

Arm-based microcontrollers

Arm-based microcontrollers forum

MSP432E401Y: How to isolate the cause of Warning: Type #10457-D Use of variable-length arrays is not thread-safe.