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.

Compiler/TMS320C6457: localD1Ev calls to a function .text:_ZNSt6localeD1Ev problems

Part Number: TMS320C6457

Tool/software: TI C/C++ Compiler

I have my final out image (elf) split into 4 sections;  these 4 sections are based upon 4 input libraries (Core.lib, img2.lib, img3.lib, img4.lib).  The core section and my 4th image (could be 2,3...doesn't matter) have some sort of bond I'm trying to resolve;  I removed a strong link by replacing the call to img4.lib from a direct call, to a function pointer.  This involved a new section for img4::main() placed at a fixed location in RAM, and then using the -undef_sym option on img4::main(). 

If I remove a function from img4.lib, the core.bin, img2,bin, and img3.bin out files all have slight changes.  This isn't expected.  There is no bond to img4.lib;  img4.lib has some functions it may call in core.lib, but that's not what I think I'm seeing.

// remove test, and the call to test in img4.lib and all other images freak out.

void test()

{

    printf ("test");

}

void class::constructor(...)

{

test();

}

It looks like one of the problems I'm having is calls to localD1Ev at my img4 address space, from the core's address space.  It is located in the dis-assembly at

.text * money_getIwSt19isstreambuf_iteratorIwSt11char_traits*...ios_base. 

Strange , because in the dis-assembly 10 lines or later, localeD1Ev is called again!  Then, 20-30 lines, it calls it again.  e.g. bae0 "CALLP.S2 localeD1Ev", dab4"CALLP.S2 localeD1Ev", dae4 "CALLP.S2 localeD1Ev", daf4 - "CALLP.S2 localeD1Ev", db80 - "CALLP.S2 localeD1Ev"...

What does localD1Ev do?  How can I get the core not to call img4's stuff, if its important?  e.g., autoinit.c calls constructors...answer is to bring file in, change it for img2,3,4 when they are loaded..and only then should the constructor be called. 

Thanks for any thoughts/solutions. 

Will

  • Symbol _ZNSt6localeD1Ev is the mangled link name for std::locale::~locale(). This is the destructor for the std::locale object (note the 'e' in the name.) The locale object is used a lot in the iostream templates and keeps track of things like what characters are considered whitespace. Our advice is to avoid iostream objects.