Project Home
Project Home
Trackers
Trackers
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - Missing something obvious: (10 Items)
   
Missing something obvious  
So I will ask and I am sure someone will point it out. 

I am currently running the 0402 build of 4.6 on Windows XP.  It is installed and being used with a QNX 632 installation.
  Regardless of my challenges from previous posts it is generally working well.

Today I decided I would try to get a remote debugging session going.  I went and found the newer version of qconn:
NAME=qconn
DESCRIPTION=QNX Connecter
DATE=2008/12/03-14:09:26-EST
STATE=stable
HOST=compbuild2
USER=pspbuild
VERSION=632-1225
TAGID=2389

After I had problems, I created the default Hello World ANSI C project and tried to debug it on my target.  My target is
 a VMware instance running the same 632 developers install that I use in Windows.  I updated it with the above mentioned
 qconn and that is it.

When I try to start it up under the debugger, the application crashes with a SIGSEGV at 0xb0031bdc - it never gets to 
main().

If I go to the target and run the uploaded exe from /tmp, it runs fine.  I can also run gdb on it and it works as 
expected.

I assume I am missing something that I need to upgrade on the target?

As far as qconn goes, I can browse everything from the target perspective (looking at processes, file system, etc..).

Any ideas?

Thanks,
Rick..
Re: Missing something obvious  
This almost certainly means that the libc.so in the vmware targets image doesn't match the libc.so in your $QNX_TARGET

Rick Duff wrote:
> So I will ask and I am sure someone will point it out. 
> 
> I am currently running the 0402 build of 4.6 on Windows XP.  It is installed and being used with a QNX 632 
installation.  Regardless of my challenges from previous posts it is generally working well.
> 
> Today I decided I would try to get a remote debugging session going.  I went and found the newer version of qconn:
> NAME=qconn
> DESCRIPTION=QNX Connecter
> DATE=2008/12/03-14:09:26-EST
> STATE=stable
> HOST=compbuild2
> USER=pspbuild
> VERSION=632-1225
> TAGID=2389
> 
> After I had problems, I created the default Hello World ANSI C project and tried to debug it on my target.  My target 
is a VMware instance running the same 632 developers install that I use in Windows.  I updated it with the above 
mentioned qconn and that is it.
> 
> When I try to start it up under the debugger, the application crashes with a SIGSEGV at 0xb0031bdc - it never gets to 
main().
> 
> If I go to the target and run the uploaded exe from /tmp, it runs fine.  I can also run gdb on it and it works as 
expected.
> 
> I assume I am missing something that I need to upgrade on the target?
> 
> As far as qconn goes, I can browse everything from the target perspective (looking at processes, file system, etc..).
> 
> Any ideas?
> 
> Thanks,
> Rick..
> 
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post29568
> 

-- 
cburgess@qnx.com
Re: Missing something obvious  
You are correct - on the target:
# cksum libc.so*
3747485823     583420 libc.so
 151268457     414052 libc.so.1
3747485823     583420 libc.so.2

On Windows:
C:\QNX630\target\qnx6\x86\lib>cksum libc.so*
2180402056     462292 libc.so
 151268457     414052 libc.so.1
2180402056     462292 libc.so.2

So how do I tell which ones is correct, and since they are both libc.so.2 why are they not compatible? 

I will copy the target version to Windows since I "know" it works in QNX ;-) and confirm that fixes the problem.

Thanks,
Rick..
Re: Missing something obvious  
But did you check which version was used for /proc/boot/libc.so?

Rick Duff wrote:
> You are correct - on the target:
> # cksum libc.so*
> 3747485823     583420 libc.so
>  151268457     414052 libc.so.1
> 3747485823     583420 libc.so.2
> 
> On Windows:
> C:\QNX630\target\qnx6\x86\lib>cksum libc.so*
> 2180402056     462292 libc.so
>  151268457     414052 libc.so.1
> 2180402056     462292 libc.so.2
> 
> So how do I tell which ones is correct, and since they are both libc.so.2 why are they not compatible? 
> 
> I will copy the target version to Windows since I "know" it works in QNX ;-) and confirm that fixes the problem.
> 
> Thanks,
> Rick..
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post29573
> 

-- 
cburgess@qnx.com
Re: Missing something obvious  
I'll be honest, I have been very confused with the whole shared library thing under qnx.  Specifically, the version 
number and how gcc selects the right one when linking and then which one is used at run time, etc, etc.

Is there be some reading I can do on the subject?

Thanks
Kevin
Re: Missing something obvious  
Kevin Stallard wrote:
> I'll be honest, I have been very confused with the whole shared library thing under qnx.  Specifically, the version 
number and how gcc selects the right one when linking and then which one is used at run time, etc, etc.
> 
> Is there be some reading I can do on the subject?

This is not specific to qnx. Here is brief introduction (in 
my own words):

When linking program, program linker (ld) looks for ".so" 
file. E.g. -lfoo looks for file named "libfoo.so". Once 
found, it reads its soname which is typically something like 
"libfoo.so.N" where N is a number.

For example, -lc will look for libc.so, then read from it 
its soname: libc.so.3. (To see library's soname, you can do 
something like: readelf -a libc.so | grep SONAME)

This soname is what is stored in executable's dynamic 
section and can be listed by

readelf -a <binary> | grep NEEDED.

At runtime, dynamic linker (ldd) uses name stored in NEEDED 
when searching for actual file.

Note that typically libfoo.so would be softlink to "the 
latest", e.g. libfoo.so.3.

Note2: To determine which exactly libraries will be pulled 
in on the target at runtime, type "ldd <binary>" on the 
target. This will tell you exactly from which directories 
will shared libraries be taken (affected by LD_LIBRARY_PATH 
and LD_PRELOAD env. vars.)


Hope this helps,

Aleksandar

Re: Missing something obvious  
Ok, I copied the target versions of the libc.so* over the files in the windows target directory and recompiled 
HelloWorld.  Unfortunately that seems to make no difference and it still crashes the same way as before.

I attached the verbose console output from gdb when it fails if that is any help.
Attachment: Text gdb_output.txt 5.5 KB
Re: Missing something obvious  
Rick Duff wrote:
> Ok, I copied the target versions of the libc.so* over the files in the windows target directory and recompiled 
HelloWorld.  Unfortunately that seems to make no difference and it still crashes the same way as before.
> 
> I attached the verbose console output from gdb when it fails if that is any help.

Unfortunately, no.

But there are a few things I would try. First, I would 
update gdb. GDB that came with 6.3.2 is 5.2.1 and is rather 
old.

First, try using newer gdb which you can download from our 
community site 
(http://community.qnx.com/sf/frs/do/listReleases/projects.toolchain/frs.gdb)


Next I would try to move qconn out of picture (for 
diagnosing this only). To do the tests I am suggesting, open 
cmd.exe, change directory to where your binary "helloworld" 
is and start gdb, for example:

C:\myworkspace\helloworld\x86\o-g\> ntox86-gdb
...
(gdb)

On your target, start pdebug like this:

# pdebug 8010


Back to your host, type in gdb this command:

(gdb) target qnx 192.168.3.128:8010
...
(gdb) upload HelloWorld /tmp/HelloWorld
...
(gdb) b main
...
(gdb) run /tmp/HelloWorld
...


It should stop at main and you should be able to step/continue.

Let me know if it worked.


Thanks,

Aleksandar
Re: Missing something obvious  
Unfortunately (or fortunately), I reinstalled both my windows and vmware
installations and it all appears to work now.  I am currently running from
the released 6.3.2 windows and qnx host installations.  On top of this I
have the 0402 ide installation and the appropriate qconn and it all appears
to be working.

Thanks for the ideas tho.

Rick..

On Tue, May 26, 2009 at 6:44 AM, Aleksandar Ristovski <
community-noreply@qnx.com> wrote:

> Rick Duff wrote:
> > Ok, I copied the target versions of the libc.so* over the files in the
> windows target directory and recompiled HelloWorld.  Unfortunately that
> seems to make no difference and it still crashes the same way as before.
> >
> > I attached the verbose console output from gdb when it fails if that is
> any help.
>
> Unfortunately, no.
>
> But there are a few things I would try. First, I would
> update gdb. GDB that came with 6.3.2 is 5.2.1 and is rather
> old.
>
> First, try using newer gdb which you can download from our
> community site
> (
> http://community.qnx.com/sf/frs/do/listReleases/projects.toolchain/frs.gdb
> )
>
>
> Next I would try to move qconn out of picture (for
> diagnosing this only). To do the tests I am suggesting, open
> cmd.exe, change directory to where your binary "helloworld"
> is and start gdb, for example:
>
> C:\myworkspace\helloworld\x86\o-g\> ntox86-gdb
> ...
> (gdb)
>
> On your target, start pdebug like this:
>
> # pdebug 8010
>
>
> Back to your host, type in gdb this command:
>
> (gdb) target qnx 192.168.3.128:8010
> ...
> (gdb) upload HelloWorld /tmp/HelloWorld
> ...
> (gdb) b main
> ...
> (gdb) run /tmp/HelloWorld
> ...
>
>
> It should stop at main and you should be able to step/continue.
>
> Let me know if it worked.
>
>
> Thanks,
>
> Aleksandar
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post30023
>
>


-- 
Rick Duff
rgduff@gmail.com

Mitch Hedberg<http://www.brainyquote.com/quotes/authors/m/mitch_hedberg.html>;
- "My fake plants died because I did not pretend to water them."
Re: Missing something obvious  
Did you also update $QNX_TARGET/x86/usr/lib/ldqnx.so.2?  That's the file that gdb would use to find
the breakpoint address, and on windoze it's not a link...

Rick Duff wrote:
> Ok, I copied the target versions of the libc.so* over the files in the windows target directory and recompiled 
HelloWorld.  Unfortunately that seems to make no difference and it still crashes the same way as before.
> 
> I attached the verbose console output from gdb when it fails if that is any help.
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post29575
> 

-- 
cburgess@qnx.com