Suppose that I have to run an application on machine 1.
Suppose also that this machine doesn’t have any screen.
How can run pdb on machine 2 to debug the software running on machine 1.
Thanks Alain.
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:
Suppose that I have to run an application on machine 1.
Suppose also that this machine doesn’t have any screen.How can run pdb on machine 2 to debug the software running on machine 1.
You need to run pdebug on the remote machine
$ pdebug 8000 &
and then in the gdb prompt connect to it
(gdb) target qnx remote_host:8000
Just to clarify, thats
target qnx target_board_ip_addr:8000 - i.e. target qnx 10.23.3.10:8000
I was trying to use remote as an option (as it is one!) as well as qnx.
Ho hum
Jim
Colin Burgess wrote in message <8skbel$9sj$6@nntp.qnx.com>…
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Suppose that I have to run an application on machine 1.
Suppose also that this machine doesn’t have any screen.How can run pdb on machine 2 to debug the software running on machine 1.
You need to run pdebug on the remote machine
$ pdebug 8000 &
and then in the gdb prompt connect to it
(gdb) target qnx remote_host:8000
Jim Atkins <jamesa@tsd.serco.com> wrote:
Just to clarify, thats
target qnx target_board_ip_addr:8000 - i.e. target qnx 10.23.3.10:8000
I was trying to use remote as an option (as it is one!) as well as qnx.
Aha, that’s your problem then.
Ho hum
Jim
Colin Burgess wrote in message <8skbel$9sj$> 6@nntp.qnx.com> >…
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Suppose that I have to run an application on machine 1.
Suppose also that this machine doesn’t have any screen.How can run pdb on machine 2 to debug the software running on machine 1.
You need to run pdebug on the remote machine
$ pdebug 8000 &
and then in the gdb prompt connect to it
(gdb) target qnx remote_host:8000
Hi Colin,
I’m in the process of converting over from using codewarrior on the PC to
using RTP for development (we’ve talked about this in the past I think with
whats occurring/not with CW).
Forgive my ignorance here but I’ve couple of noddy questions on the
subject:
-
I presume then that for my target platform I will want to swap over the
C/C++ libraries (gnu rather than metrowerks) etc. -
Anything else fundamental changed as far as image files is concerned
between Neutrino 2.0 and RTP)? -
I will now be developing on a host machine with RTP and running code and
debugging it over the ether using ddd ( my target board has in house cards
attached which I can’t test on the host). Whats the best way to do this
then? Do I build the code and then transfer the executable to the target
manually before running ddd? If so how do I kick ddd off - how do I specify
what executable its debugging bearing in mind that the source is on the
host? Do I just run ddd ‘./progname’ and hope that the executable on the
target is the same or is there a kind of upload facility? As I say please
forgive my ignorance - this is new stuff to me.
Regards
Jim
Jim Atkins <jamesa@tsd.serco.com> wrote:
Hi Colin,
I’m in the process of converting over from using codewarrior on the PC to
using RTP for development (we’ve talked about this in the past I think with
whats occurring/not with CW).
Forgive my ignorance here but I’ve couple of noddy questions on the
subject:
- I presume then that for my target platform I will want to swap over the
C/C++ libraries (gnu rather than metrowerks) etc.
Yes. Note that we will be moving to the Dinkum C/C++ libs fairly soon,
which will give you another (non GPL) C++ lib alternative.
- Anything else fundamental changed as far as image files is concerned
between Neutrino 2.0 and RTP)?
The type of compression used to compress the image changed to a non GPL
algorithm, so your mkifs and startup must match, but if you are building
your image on the RTP all should be fine.
- I will now be developing on a host machine with RTP and running code and
debugging it over the ether using ddd ( my target board has in house cards
attached which I can’t test on the host). Whats the best way to do this
then? Do I build the code and then transfer the executable to the target
manually before running ddd? If so how do I kick ddd off - how do I specify
what executable its debugging bearing in mind that the source is on the
host? Do I just run ddd ‘./progname’ and hope that the executable on the
target is the same or is there a kind of upload facility? As I say please
forgive my ignorance - this is new stuff to me.
Download your files to the target machine.
On your target:
$ export LD_LIBRARY_PATH=path_to_where_your_shared_objects_are_on_target
$ pdebug 8000 &
run ddd (no args)
Then in the gdb console:
connect
(gdb) target qnx remote_ip:8000
make sure target environment is used, not host environment
(gdb) set qnxinheritenv 1
tell gdb where to find symbols for shared objects
(gdb) set solib-search-path path_to_where_your_shared_objects_are_on_host
load symbols of executable
(gdb) sym path_to_program_on_host
launch program on remote target
(gdb) run path_to_program_on_target args
set breakpoint at main
(gdb) break main
set program running
(gdb) cont
Colin Burgess <cburgess@qnx.com> wrote:
Jim Atkins <> jamesa@tsd.serco.com> > wrote:
Hi Colin,I’m in the process of converting over from using codewarrior on the PC to
using RTP for development (we’ve talked about this in the past I think with
whats occurring/not with CW).
Forgive my ignorance here but I’ve couple of noddy questions on the
subject:
- I presume then that for my target platform I will want to swap over the
C/C++ libraries (gnu rather than metrowerks) etc.Yes. Note that we will be moving to the Dinkum C/C++ libs fairly soon,
which will give you another (non GPL) C++ lib alternative.
- Anything else fundamental changed as far as image files is concerned
between Neutrino 2.0 and RTP)?The type of compression used to compress the image changed to a non GPL
algorithm, so your mkifs and startup must match, but if you are building
your image on the RTP all should be fine.
- I will now be developing on a host machine with RTP and running code and
debugging it over the ether using ddd ( my target board has in house cards
attached which I can’t test on the host). Whats the best way to do this
then? Do I build the code and then transfer the executable to the target
manually before running ddd? If so how do I kick ddd off - how do I specify
what executable its debugging bearing in mind that the source is on the
host? Do I just run ddd ‘./progname’ and hope that the executable on the
target is the same or is there a kind of upload facility? As I say please
forgive my ignorance - this is new stuff to me.
Hello,
I have just added this issue to the Knowlege Base at http://qnd.qnx.com.
You can find the solution to this issue, by searching on “ddd”.
You’ll also find the answer at the following link:
http://support.qnx.com/support/bok/solution.qnx?10140
Best Regards,
Marcin
Download your files to the target machine.
On your target:
$ export LD_LIBRARY_PATH=path_to_where_your_shared_objects_are_on_target
$ pdebug 8000 &run ddd (no args)
Then in the gdb console:
connect
(gdb) target qnx remote_ip:8000
make sure target environment is used, not host environment
(gdb) set qnxinheritenv 1
tell gdb where to find symbols for shared objects
(gdb) set solib-search-path path_to_where_your_shared_objects_are_on_host
load symbols of executable
(gdb) sym path_to_program_on_host
launch program on remote target
(gdb) run path_to_program_on_target args
set breakpoint at main
(gdb) break main
set program running
(gdb) cont
–
Marcin Dzieciol
Technical Support
QNX Software Systems Ltd.
Email: <marcind@qnx.com>
Colin Burgess <cburgess@qnx.com> wrote:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Suppose that I have to run an application on machine 1.
Suppose also that this machine doesn’t have any screen.
Hello,
I have just added this issue to the Knowlege Base at http://qnd.qnx.com.
You can find the solution to this issue, by searching on “pdb”.
You’ll also find the answer at the following link:
http://support.qnx.com/support/bok/solution.qnx?10139
Best Regards,
Marcin
How can run pdb on machine 2 to debug the software running on machine 1.
You need to run pdebug on the remote machine
$ pdebug 8000 &
and then in the gdb prompt connect to it
(gdb) target qnx remote_host:8000
–
Marcin Dzieciol
Technical Support
QNX Software Systems Ltd.
Email: <marcind@qnx.com>