troubles compiling C++

QNX Newsgroups (Archives) qdn.public.qnxrtp.newuser
#1

We’re having a lot of trouble with using C++ on your PC-104 (Arcom) SBC’s.

We keep getting “Memory Error” and I’m at loss of how to debug this. How
do I know whether I’m just running out of memory as opposed to a segfault?
How do I even check how much memory I’m using vs. what’s free?

Also, is there an equivalent of the Linux ‘ldd’ command?

Any hints as to how I can work on debugging it would be appreciated.

Dana

Setup:

devel system: PIII, running plain patch A (installed from QNX CD,
nothing major touched) (just /etc/passwd, etc…)


target: Arcom Elan board running an image built on the Pentium
with libstc++.so copied over from the pentium onto the target.


Source file:


#include <iostream.h>

int main (int argc, char *argv[])
{
cout << “Hello world \n”;
return (0);
}


Situation 1:

When compiled with

g++ -g -static hello.c -L/usr/lib -o hello

It runs fine on the devel system, but on the target it gives a Memory Fault.
When run with gdb, I get
\
\
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x8055734 in _init_libc ()
(gdb)
\
\
Situation 2:

When compiled with

g++ -g hello.c -o hello

it runs on both systems.


Situation 3:

A longer C++ program instead of "hello world" is used.

When compiled with

g++ -gstabs etc..etc.. (normal dynamic linking)
it runs normally on the development
systems, but gives a memory fault on the target.

When run with GDB, the error is:

(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x804a122 in __do_global_ctors_aux ()
(gdb)
\
\
\
--
Dana Echtner             \  Real-Time Systems Administrator
<dana@ece.concordia.ca>    /   ECE, Concordia University, Montreal, Canada

rw-rw-rw-:  The file protection of the beast
#2

Hmmmm, for one you should have libstdc++.so.2.10 rather than just
libstdc++.so on your target.

I would check for other lib dependencies as well.

I’ve put a hacked up ldd script on

http://staff.qnx.com/~cburgess/freestuff

Dana Echtner <dana@ece.concordia.ca> wrote:

We’re having a lot of trouble with using C++ on your PC-104 (Arcom) SBC’s.

We keep getting “Memory Error” and I’m at loss of how to debug this. How
do I know whether I’m just running out of memory as opposed to a segfault?
How do I even check how much memory I’m using vs. what’s free?

Also, is there an equivalent of the Linux ‘ldd’ command?

Any hints as to how I can work on debugging it would be appreciated.

Dana

Setup:

devel system: PIII, running plain patch A (installed from QNX CD,
nothing major touched) (just /etc/passwd, etc…)



target: Arcom Elan board running an image built on the Pentium
with libstc++.so copied over from the pentium onto the target.



Source file:



#include <iostream.h

int main (int argc, char *argv[])
{
cout << “Hello world \n”;
return (0);
}



Situation 1:

When compiled with

g++ -g -static hello.c -L/usr/lib -o hello

It runs fine on the devel system, but on the target it gives a Memory Fault.
When run with gdb, I get



(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x8055734 in _init_libc ()
(gdb)



Situation 2:

When compiled with

g++ -g  hello.c -o hello

it runs on both systems.



Situation 3:

A longer C++ program instead of "hello world" is used.

When compiled with

g++ -gstabs etc..etc.. (normal dynamic linking)
it runs normally on the development
systems, but gives a memory fault on the target.

When run with GDB, the error is:

(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x804a122 in __do_global_ctors_aux ()
(gdb)



–
Dana Echtner \ Real-Time Systems Administrator
dana@ece.concordia.ca > / ECE, Concordia University, Montreal, Canada

rw-rw-rw-: The file protection of the beast

–
cburgess@qnx.com

#3

Colin Burgess wrote:

Hmmmm, for one you should have libstdc++.so.2.10 rather than just
libstdc++.so on your target.

Well yes, I do. (Sorry, my fault, I thought that would be obvious)

I would check for other lib dependencies as well.

I’ve put a hacked up ldd script on

Thanks!
I’ve tried it out and the lib dependencies look fine. I get output like

Shared libs neede by myprog

/lib/libc.so.1
/lib/libm.so.1
/usr/lib/libstdc++.so.2.10

The other reason I don’t think it’s the libraries was that when I had some
missing before, gdb complained. Now gdb is happy about libraries.

http://staff.qnx.com/~cburgess/freestuff

Hey, rdate!!!

Excellent, I really needed that. (using NFS for home directories,
students were getting all kind of “clock skew detected” errors.)

Thanks! :slight_smile:

–
Dana Echtner \ Real-Time Systems Administrator
dana@ece.concordia.ca / ECE, Concordia University, Montreal, Canada

rw-rw-rw-: The file protection of the beast

#4

Thinking about this a little, it seems that both of the
target system failure cases are related to the size of
the binary. The static version is going to be huge
compared to the dynamic, and the stabs debugging version
is also going to be huge.

Try stripping the stabs version that you run on the target, eg

strip -o file.nodebug file.debug

then use the debug version for debugging syms, and the non debug
version for running.

Also - does the static version crash if you don’t have the
shared libstdc++.so on your target system?

Dana Echtner <dana@ece.concordia.ca> wrote:

We’re having a lot of trouble with using C++ on your PC-104 (Arcom) SBC’s.

We keep getting “Memory Error” and I’m at loss of how to debug this. How
do I know whether I’m just running out of memory as opposed to a segfault?
How do I even check how much memory I’m using vs. what’s free?

Also, is there an equivalent of the Linux ‘ldd’ command?

Any hints as to how I can work on debugging it would be appreciated.

Dana

Setup:

devel system: PIII, running plain patch A (installed from QNX CD,
nothing major touched) (just /etc/passwd, etc…)



target: Arcom Elan board running an image built on the Pentium
with libstc++.so copied over from the pentium onto the target.



Source file:



#include <iostream.h

int main (int argc, char *argv[])
{
cout << “Hello world \n”;
return (0);
}



Situation 1:

When compiled with

g++ -g -static hello.c -L/usr/lib -o hello

It runs fine on the devel system, but on the target it gives a Memory Fault.
When run with gdb, I get



(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x8055734 in _init_libc ()
(gdb)



Situation 2:

When compiled with

g++ -g  hello.c -o hello

it runs on both systems.



Situation 3:

A longer C++ program instead of "hello world" is used.

When compiled with

g++ -gstabs etc..etc.. (normal dynamic linking)
it runs normally on the development
systems, but gives a memory fault on the target.

When run with GDB, the error is:

(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x804a122 in __do_global_ctors_aux ()
(gdb)



–
Dana Echtner \ Real-Time Systems Administrator
dana@ece.concordia.ca > / ECE, Concordia University, Montreal, Canada

rw-rw-rw-: The file protection of the beast

–
cburgess@qnx.com

#5

Colin Burgess wrote:

Thinking about this a little, it seems that both of the
target system failure cases are related to the size of
the binary. The static version is going to be huge
compared to the dynamic, and the stabs debugging version
is also going to be huge.

Hmmm, you might be right.

How can I find out how much memory I have free?

Is there some tool that will let me figure out if I’m just running out of
memory?

D.

\

Dana Echtner \ Real-Time Systems Administrator
dana@ece.concordia.ca / ECE, Concordia University, Montreal, Canada

rw-rw-rw-: The file protection of the beast

#6

Dana Echtner <dana@ece.concordia.ca> wrote:

Colin Burgess wrote:

Thinking about this a little, it seems that both of the
target system failure cases are related to the size of
the binary. The static version is going to be huge
compared to the dynamic, and the stabs debugging version
is also going to be huge.

Hmmm, you might be right.

How can I find out how much memory I have free?

pidin info will show memory information

Is there some tool that will let me figure out if I’m just running out of
memory?

I don’t think so. The program is probably crashing because a malloc
failed, but the way it crashes is indistinguishable from other SIGSEGV
causes.

–
cburgess@qnx.com

#7

Colin Burgess wrote:


pidin info will show memory information

I get

CPU:X86 Processors:1 FReeMem: 11Mb/16Mb etc…

Am I reading correctly that I have 11megabytes free?

If that’s the case, I don’t see how a 300K binary would fail to load…

I don’t think so. The program is probably crashing because a malloc
failed, but the way it crashes is indistinguishable from other SIGSEGV
causes.

And there is no way to distinguish it? (If I was doin the malloc manually
I could just catch the error code but my program doesn’t even malloc, it
just does one printf…)

D.

–
Dana Echtner \ Real-Time Systems Administrator
dana@ece.concordia.ca / ECE, Concordia University, Montreal, Canada

rw-rw-rw-: The file protection of the beast

#8

Dana Echtner <dana@ece.concordia.ca> wrote:

Colin Burgess wrote:



pidin info will show memory information

I get

CPU:X86 Processors:1 FReeMem: 11Mb/16Mb etc…

Am I reading correctly that I have 11megabytes free?

Yes.

If that’s the case, I don’t see how a 300K binary would fail to load…

Beats me, at the moment. What does pidin info say when you
have it crashed in the debugger?


I don’t think so. The program is probably crashing because a malloc
failed, but the way it crashes is indistinguishable from other SIGSEGV
causes.

And there is no way to distinguish it? (If I was doin the malloc manually
I could just catch the error code but my program doesn’t even malloc, it
just does one printf…)

D.

–
Dana Echtner \ Real-Time Systems Administrator
dana@ece.concordia.ca > / ECE, Concordia University, Montreal, Canada

rw-rw-rw-: The file protection of the beast

–
cburgess@qnx.com