C++ static constructor problems
Kurt Lloyd
are giving us major grief. We link, we munch, we link
again, and we download, but only *some* of the appropriate
constructors fire. Even though the _ctors file from the
munch has symbols for all the files with the constructors
we expect.
Some of these objects invoke semMCreate() in their
constructor initializers. Later, once a task is spawned
from the load, semTake() fails because semMCreate() had
not been called. We placed printfs in object constructors
to see which ones got called. Some got called, some did not.
We tried changing the constructor strategy from being done
automatically during load to doing it manually via the
cplusCtors(0) function. If we run this from windsh then
we get the same result as when we download in automatic
mode.
We want to use Crosswind to debug, but have spent hours
failing at this. Breakpoints don't get stopped during
load when using automatic mode. Breaking at the task's
spawn function, starting the task from Crosswind, and
then calling cplusCtors(0) from Crosswind doesn't enable
us to step through cplusCtors().
If I write a new C++ spawn function which calls cplusCtors(0)
and then the original spawn function, and run it through
Crosswind, cplusCtors() fails to run *any* of the
constructors, as it seems to be failing to get a semaphore
of some kind itself.
Bottom line is that all attempts at debugging have failed.
Any suggestions or relevant experiences would be appreciated.
Also, especially regarding running semMCreate() from static
object constructors, is this something I should expect to
be able to do?
By the way, just so you know, I personally prefer software
that does not do this sort of thing. But this is software
that's already been written that's doing this, for example,
RoseRT code.
-Kurt Lloyd, kpl...@lucent.com, (978) 960-6276
CPU: Wind River. SBC8260 -- MPC8260 PowerQUICC II SBC
VxWorks: 5.4
BSP version: 1.2/29
Creation date: Sep 25 2001
molochai
kpl...@lucent.com (Kurt Lloyd) wrote:
> C++ object constructors typically invoked during load
> are giving us major grief. We link, we munch, we link
> again, and we download, but only *some* of the appropriate
> constructors fire. Even though the _ctors file from the
> munch has symbols for all the files with the constructors
> we expect.
>
Never seen static constructors not being called at all, but *have* seen them
get called multiple times (similarly destructors).
If calls to static constructor are generated in several compilation units (as
is practically innevitable) several calls to static constructors can result
from different places in the final linked program. GCC 2.95.4 gets this
right by checking that the static constructor has not previously been called,
however the GCC with Tornado II does not.
Debugging static constructors during download with Crosswinds is not going to
work as constructors/destructors are called from within the tWdbTask context
which also provides target agent services to CrossWinds.
Manually calling the constructors from the host shell will suffer from the
same problem. You could try spawning it as a task instead.
[snip]
M
James Boucher
up which might be a follow-on problem. What we found was that the
ppc compiler was using the C definition of static (ie file scope). In a
trivial
example, I was able to get a static class constructor to work as desired
(one instance from multiple calls to ::instance() by including the .cpp in
the single source file. This works as, in this simple case, there is only
one file scope. For the more complex case, we did the following (note we
saw the semM problems just like you did before this, but I think it was more
due to a memory corruption that was fixed the same time we fixed the static
constructor problem).
//in a higher class mytestclass .h->
myclass & mystaticclass;
---------
//in a higher class mytestclass .cpp->
mytestclass::mytestclass()
:mystaticclass(mystaticclass::instance())
{
....
}
----------------------
in the myclass .cpp
myclass & myclass::instance()
{
static myclass mysingleton;
return mysingleton;
}
This approach seems to be working even with some templating thrown in. From
here, what is the problem you see?
Jim
"molochai" <molo...@vapour-trail.demon.co.uk> wrote in message
news:e03758c44a%molo...@vapour-trail.demon.co.uk...
Christian Delez
> are giving us major grief.
>
> failing at this.
>
Hi,
There is a really good explanation about constructors strategy and how
to debug them in using CrossWind or gdb. I've been able to debug my
statics object on the same kernel, same hardware. All is in a
WindRiver technical note:
=> Tech Tips: "A Tornado User's Guide to C++ Member Functions" - Last
modified: Jan 11 2001.
To get it, you must be a WindRiver registred user with a valid support
contract. Then go to http://www.wrs.com/corporate/html/tsmain.html and
then click on WindSurf login. WindSurf is the WindRiver customer
support site. If you don't have access, ask WindRiver for one.
Prototyper users should also have access to this database.
Concerning semMCreate() problem, if it still fail after debug, make a
query on the WindSurf support database. There's maybe something.
@+, Christian