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.

Possible size issue with "new" operator in C66x CGTv8.0.1

Hi,

Some engineers are developing C++ on C66 and have come across an issue with the "new" operator.  For certain classes, the size argument is garbage.  Much like the following issue here:

https://e2e.ti.com/support/development_tools/compiler/f/343/t/484804

This is not easily represented in a small isolated project (occurs in very large project and only on certain classes), so appears there could higher level issues present.

Using 8.0.1, with -qq -pdsw225 -ppa -)off -symdebug:dwarf -mv6600 --abi=eabi

Please pass along any thoughts on how to further isolate and whether there are any known issues/constraints with "new".  Assume validation of .sysmem section reservation will be one (and increasing system heap).  Also, looking for similarities in classes which exhibit the issue (public/private/etc).

Thanks,

Eric 

  • Hi

    In the issue you quote the class turned out to be really big, and I suspect that that is going to be the case here as well. It would be a good idea to see what sizeof(classinquestion) is, and to recursively track its largest member.

  • Markus Moll said:
    It would be a good idea to see what sizeof(classinquestion) is

    I agree.  A good way to do that is to write a short C++ file that looks similar to this ...

    include "header_that_declares_class_in_question.h"
    
    int fxn()
    {
       return sizeof(class_in_question);
    }

    Build that file with the option --src_interlist.  Among other things, this option causes the compiler generated assembly file to be kept.  This file has the same name as the source file, with the extension changed to .asm.  Inspect the file.  Near the end of the function, a constant will be copied to A4.  This constant is the size of the class.

    Thanks and regards,

    -George

  • Bear in mind that that just gives you the size of the raw object, which can be misleadingly small. Consider a container object: sizeof will be quite small, but if the container holds a lot of objects, the memory footprint can be quite large.