problems using <map> STL template on PowerPC

I’ve been prototyping an application on QNX RTP 6.1 Patch A over X86. This
applications uses the and templates from the Dinkum C++ STL
(libcpp.so). When I recompile and run the application on my PowerPC 860
target I get some strange behavior with the template.

For one thing, any simple program that uses a map (even if it is as simple
as map<int, char>) gets a SIGSEGV after return from main(). I step through
the program with gdb and I see the exception occur immediately after
returning from
main().

Secondly, I have a class that I’ve implemented that has a map as one of
its data members. Depending on the code I place in that class’ constructor
I get a SIGILL while the loader is loading the program. From what I can
tell in gdb, it appears as though the the CPU is jumping into an area of
libcpp.so that contains all 0’s. The crazy thing is that there are no static
instances of this class so the constructor code should not even be executed
before getting into main().

I’ve been in discussion with QSSL over this but I would like to know if
anybody else in the QNX community has ever encountered any behavior like
this. I would greatly appreciate hearing about any experiences people have
had writing C++ applications for QNX RTP on PowerPC.

I’ve included an e-mail sent to QSSL describing some of the problems I’ve
seen at the end of this post.

Thanks in advance for any feedback,

Denis Leclair
denis.leclair@sympatico.ca



Hi ----,

As per our conversation, here is a sample program that gets SIGSEGV after
returning form
main() on PowerPC 860. The exact output is as follows:

load_object: attempt load of libcpp.so.2
load_elf32: mmaped, addr 0 0 vaddr fe363000
load_elf32: loaded lib at addr fe363000(text) fe41dea0(data)
load_object: attempt load of libm.so.2
load_elf32: loaded lib at addr fe427000(text) fe439360(data)
my_map[1] = a

Process 40969 (test_map2) terminated SIGSEGV code=1 fltno=11 ip=00000020
mapaddr=00000000.
…/test_map2 terminated with signal 11


Stepping through this program with GDB shows that the SIGSEGV occurs
immediately after
returning from main().

The second problem with the template that I am investigating is as
follows:

I have a class that looks something like this:

class Foo {
public:
Foo();

private:
typedef map<ClassA, ClassB > MyMapType; / mapping of ClassA to
pointers to ClassB /
MyMapType my_map; /
declare a MyMapType data
member */
};

I happen to package the Foo class in a shared object (e.g. libfoo.so) that
ultimately gets
linked with my binary at load time.

Now, here’s the problem. If I leave Foo’s constructor empty as follows

Foo::Foo()
{
}

…then the compiler should add an implicit call to the default constructor
of
map<ClassA, ClassB *> and everything should be fine.

Finally, I create a main program that has NO reference to class Foo:

int main()
{
// make no reference to Foo whatsoever
}

and then compile main linking in libfoo.so shared object:
QCC -Vgcc_ntoppcbe -L. -oblah main.cc -lfoo

‘blah’ compiles fine but when I run it on my PPC 860 target I get a SIGILL
even before
entering main().

What is very strange with all this is if I modify Foo’s constructor to the
following:
Foo::Foo()
{
my_map = MyMapType();
}

If I understand this correctly, this creates a temporary MyMapType object
and copies it to
my_map. By adding this one line, the SIGILL does not occur even though my
code makes no
reference to Foo in any way.

I have not been able to bring this second problem down to a small example
for you to try
at your end but I will continue to try to do this over the next day or so.

I would greatly appreciate it if you could let me know of any outstanding
issues found in
STL on PPC.

Thanks,

Denis Leclair
denis.leclair@sympatico.ca