Code that works on another platform, not with CrossWorks
This is perhaps more of a generic thing, i.e., from what answers might look like, I guess, unless somebody had very similar problems.
Scenario:
I fetched some code off my codebase, C++, to be used in my embedded project, using lots of more or less complicated templates & stuff, but no operator new / delete. (using a custom allocation scheme not overloading new)
Made everyting compile just fine, both, in Visual C++ 2010, and CrossWorks (2.1 and 2.2). (I have a MSVC project including only non-system specific code of my STM32 project, so I can test said stuff on windows).
I wrote a couple of tests which check the bevavior of the mentioned code.
All tests pass fine in VC++/Windows.
But in CrossWorks, on my stm32 board, some tests not only don't pass, but remain in an infinite loop because some object's data contain wrong values.
Now, the init & actual testing code are identical on both platforms.
I even had the tests start on the stm32 before setting up any other peripherals or interrupts, to avoid possible side effects, aside from setting the clock to full 24MHz and enabling the systick (which polls the user button and sets an LED ... no wild stuff)
So, this is rather weird.
From debugging so far, I could not make sense out of this, and it's kind of mindboggling to even attempt to debug this - what am I looking for? It can't be defective code that I could possibly fix, since it has been confirmed working (for the given tested feature subset),
so this is kind of giving me stomach ache right now.
Alas, my debugging facilities are quite comprimised right now (see other thread - I don't know if that problem has anything to do with this).
EDIT:
Btw., I gave the __cxa_guard_acquire/release emtpy implementations (where I have static objects in functions, no muli "thread" access is used currently), but I guess it shouldn't matter since all those things would do if used from a library, is, lock on a mutex, no?
Any ideas?
-
Weird !
The stuff now works.Change: The one static object inside the one (also static) member function is now a static member of the class, and initialized outside the class def (which I was too lazy to do before).
This object happens to be my allocator, which gave always the same address for each in a sequence of allocation requests, because the correctly set to "used" marker bits, which would mark blocks as used, would be zero again on next call - as if the implementation wasn't really done static, and thus, the marker bits set to zero again each time ...
Since this worked fine on MSVC++, I wonder: does GCC handle this differently from MSVC, is this standards gray area or did I do anything wrong?
To illustrate:
class List
{
private:
class Node
{
static Node* Create()
{
Node* n = allocator_instance().Allocate();
n->SetThoseAndTheseValues();
return n;
}
};
// does not work on crossworks/stm32, gives always same address (first block), since markers all zero.
// On MSVC++, this works fine.
//static Allocator<Node> & allocator_instance()
//{
// static Allocator<Node> alloc;
// return alloc;
// }
// this works
static Allocator<Node> alloc;
static Allocator<Node> & allocator_instance()
{
return alloc;
}
};
Now, this is simplified a lot, the allocator thingy is quite woven into templat-o-mania, but the only difference between works vs. doesn't work was the location change of the static variable.
Ah, just read the new post: Stack size was 1024.
I'll do some exteded tests whether this is really fine and dandy, and not just for some reason the couple tests passing...
and post the results here later, maybe some people besides me finds that interesting :-) -
Confirmed:
I put a global counter inside the ctor of Allcoator...
On the CrossWorks/GCC version, the constructor of Allocator gets called for each time allocator_instance() is called, in the version with static Allocator<Node> alloc; inside the static function.
I'd say, this should not be happening, am I missing something?I just replicated this behavior with simple classes, without any template stuff going on behind the scenes.
-
Something has to set the bottom bit of the guard object - see http://infocenter.arm.com/help/topic/com.arm.doc.ihi0041c/IHI0041C_cppabi.pdf
I guess your empty __cxa_guard_acquire/release implementations need to be filled out a bit.....
Please sign in to leave a comment.
Comments
5 comments