Further to my previous post…
If i run ntox86-gdb from the command line (windows host), I can
perform the following to debug my code
target ip:port
symbol-file myprog
run myprog ← having uploaded it manually or via ‘upload myprog
destination’
break main
continue
- it now spits out some errors, but seems to continue just fine…
Error while mapping shared library sections:
libcpp.so.4: No such file or directory.
Error while mapping shared library sections:
libc.so.2: No such file or directory.
Error while reading shared library symbols:
libcpp.so.4: No such file or directory.
Error while reading shared library symbols:
libc.so.2: No such file or directory.
- it now breaks at the start of main
[list:f50ff600b5]continue[/list:u:f50ff600b5]
- it now continues successfully to the end
If i try the same thing from the console within the Momentics IDE on
the Windows host, after starting a debug session, it causes the
SIGSEGV behaviour - seemingly before actually entering main(), though
i’m not 100% sure about this. No symbols can be resolved, and for some
reason there are always 6 frames in the stack:
Thread [1] (Suspended: Signal ‘SIGSEGV’ received. Description:
Segmentation fault.)
6 0xb0331bdc
5 0xb0331c16
4 0xb0331d9d
3 0xb03348fb
2 0xb0334b03
1 0xb0332e41
This behaviour seems to occur with any program i try to debug from
within the Momentics IDE (even telling it to run other files already
on the QNX target causes the same problem), and I can’t repeat it
from the command line debugger, on either windows or QNX hosts.
Incidently, it looks like the warnings about “No such file or
directory” from the original post are to do with the ‘directory’
search list set up for gdb when it is run. From the windows host, it
is supplying one of the paths as C:\QNX630… etc instead of
/cygdrive/c/QNX630/… so it breaks up the path in the wrong spot.
Adding the invalid paths to my command line instances of GDB didn’t
break them, nor did adding the corrected paths to my Momentics GDB
fix it, so looks like that’s unrelated…
I can see that Momentics is calling “attach” to a PID,
whereas i’m debugging using “run” on a file on the remote
system… this seems to be the only real difference betwen the two,
but I"m not entirely sure what’s going on there yet…