Hi,
As you see following example, we can not debug remotely with target system.
We can see that the gdb program is in the received-blocking mode
with io-net from pidin.
I guess the “pdebug” for SH4 platform has a bug from showing “Wrong endian”.
Please let me know how to configure the correct endian in “pdebug” and solve
it.
---------------- target SH4 ----------------
ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4): 56 data bytes
64 bytes from 192.168.0.4: icmp_seq=0 ttl=255 time=1 ms
64 bytes from 192.168.0.4: icmp_seq=1 ttl=255 time=1 ms
…
export PDEBUG_DEBUG=1
pdebug 8000 &
20488 running pdebug
This version of pdebug was built on Jun 22 2001.
ProtoVer 0.1
Com port 8000 initialized ok.
Target initialized ok.
pdebug initialized
TargetDisconnect
TargetEnv: Clearing Environment
TargetEnv: Clearing Arguments
Wrong endian.
ResponseErr err=22
TargetDisconnect
TargetEnv: Clearing Environment
TargetEnv: Clearing Arguments
TargetConnect major=0 minor=1
ResponseOkStatus status=1056
-------------- host ----------------
ntosh-gdb
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “–host=x86-pc-nto-qnx --target=ntosh”.
(gdb) target qnx 192.168.0.44:8000
Remote debugging using 192.168.0.44:8000
??? There is no prompt for the next procedure. Maybe it is pending …
Thanks in advance.
Byoung-Hweh Huh
purunsan@rtsolutions.co.kr
“Byoung-Hweh Huh” <purunsan@orgio.net> wrote in message
news:a01brv$p2s$1@inn.qnx.com…
Hi,
As you see following example, we can not debug remotely with target
system.
We can see that the gdb program is in the received-blocking mode
with io-net from pidin.
I guess the “pdebug” for SH4 platform has a bug from showing “Wrong
endian”.
Please let me know how to configure the correct endian in “pdebug” and
solve
it.
The problem is not with pdebug, but with the version of gdb you’re using –
gdb is compiled for x86 and is choking on the SH4 bin. You need to run
/usr/bin/ntosh-gdb.
DDD is a nice X11 GUI for gdb and is much easier to use than the CLI. You
could invoke it as:
ddd --debugger /usr/bin/ntosh-gdb &
Don’t use the buttons that appear in a seperate small window – they don’t
work. Just close that window.
You could save yourself a bit of typing by creating an initialization file
on the Host called “.gdbinit”
target qnx 192.168.0.4:8000
set qnxinheritenv
set qnxremotecwd /usr/local/bin
set auto-solib-add 1
sym hello
run hello
b main
cont
This assumes the executable has been copied to the target and pdebug will
find it in the target’s /usr/local/bin
Note the “sym hello” is a directive to gdb running on the Host, whereas “run
hello” is a directive to pdebug running on the target.
Make sure you compile with the ‘-g’ flag and don’t use the ‘-O’ flag.
Cheers,
David S. Alessio
Systemic Realtime Design, LLC
Thanks for your reply.
I have also run the “/usr/bin/ntosh-gdb”, not gdb for x86.
When I command “target qnx 192.168.0.4:8000” in the prompt of ntosh-gdb,
there was no prompt. It is just like pending…
Thanks anyway and in advance.
“David S. Alessio” <david@NOsysrtimeSPAM.com> wrote in message
news:a06j49$aop$1@inn.qnx.com…
“Byoung-Hweh Huh” <> purunsan@orgio.net> > wrote in message
news:a01brv$p2s$> 1@inn.qnx.com> …
Hi,
As you see following example, we can not debug remotely with target
system.
We can see that the gdb program is in the received-blocking mode
with io-net from pidin.
I guess the “pdebug” for SH4 platform has a bug from showing “Wrong
endian”.
Please let me know how to configure the correct endian in “pdebug” and
solve
it.
The problem is not with pdebug, but with the version of gdb you’re
using –
gdb is compiled for x86 and is choking on the SH4 bin. You need to run
/usr/bin/ntosh-gdb.
DDD is a nice X11 GUI for gdb and is much easier to use than the CLI. You
could invoke it as:
ddd --debugger /usr/bin/ntosh-gdb &
Don’t use the buttons that appear in a seperate small window – they don’t
work. Just close that window.
You could save yourself a bit of typing by creating an initialization file
on the Host called “.gdbinit”
target qnx 192.168.0.4:8000
set qnxinheritenv
set qnxremotecwd /usr/local/bin
set auto-solib-add 1
sym hello
run hello
b main
cont
This assumes the executable has been copied to the target and pdebug will
find it in the target’s /usr/local/bin
Note the “sym hello” is a directive to gdb running on the Host, whereas
“run
hello” is a directive to pdebug running on the target.
Make sure you compile with the ‘-g’ flag and don’t use the ‘-O’ flag.
Cheers,
David S. Alessio
Systemic Realtime Design, LLC
\
Byoung-Hweh Huh <purunsan@orgio.net> wrote:
: Thanks for your reply.
: I have also run the “/usr/bin/ntosh-gdb”, not gdb for x86.
: When I command “target qnx 192.168.0.4:8000” in the prompt of ntosh-gdb,
: there was no prompt. It is just like pending…
gdb is trying to connect to the debug target.
You have to run pdebug on the target machine.
telnet 192.168.0.4
…
pdebug 8000
: Thanks anyway and in advance.
Byoung-Hweh Huh <purunsan@orgio.net> wrote:
Hi,
Hello,
As you see following example, we can not debug remotely with target system.
We can see that the gdb program is in the received-blocking mode
with io-net from pidin.
I guess the “pdebug” for SH4 platform has a bug from showing “Wrong endian”.
Please let me know how to configure the correct endian in “pdebug” and solve
it.
---------------- target SH4 ----------------
ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4): 56 data bytes
64 bytes from 192.168.0.4: icmp_seq=0 ttl=255 time=1 ms
64 bytes from 192.168.0.4: icmp_seq=1 ttl=255 time=1 ms
…
export PDEBUG_DEBUG=1
pdebug 8000 &
20488 running pdebug
This version of pdebug was built on Jun 22 2001.
ProtoVer 0.1
Com port 8000 initialized ok.
Target initialized ok.
pdebug initialized
TargetDisconnect
TargetEnv: Clearing Environment
TargetEnv: Clearing Arguments
Wrong endian.
ResponseErr err=22
TargetDisconnect
TargetEnv: Clearing Environment
TargetEnv: Clearing Arguments
TargetConnect major=0 minor=1
ResponseOkStatus status=1056
-------------- host ----------------
ntosh-gdb
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “–host=x86-pc-nto-qnx --target=ntosh”.
(gdb) target qnx 192.168.0.44:8000
Remote debugging using 192.168.0.44:8000
??? There is no prompt for the next procedure. Maybe it is pending …
What is your host? (Win, Sol or RTP), What version/release is it?
What type of SH4 board are you using?
Can you ping your target from host?
Regards,
Marcin
Thanks in advance.
Byoung-Hweh Huh
purunsan@rtsolutions.co.kr
“Tools Mail Account” <tools@qnx.com> wrote in message
news:a14itj$sed$1@nntp.qnx.com…
Byoung-Hweh Huh <> purunsan@orgio.net> > wrote:
Hi,
Hello,
As you see following example, we can not debug remotely with target
system.
We can see that the gdb program is in the received-blocking mode
with io-net from pidin.
I guess the “pdebug” for SH4 platform has a bug from showing “Wrong
endian”.
Please let me know how to configure the correct endian in “pdebug” and
solve
it.
---------------- target SH4 ----------------
ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4): 56 data bytes
64 bytes from 192.168.0.4: icmp_seq=0 ttl=255 time=1 ms
64 bytes from 192.168.0.4: icmp_seq=1 ttl=255 time=1 ms
…
export PDEBUG_DEBUG=1
pdebug 8000 &
20488 running pdebug
This version of pdebug was built on Jun 22 2001.
ProtoVer 0.1
Com port 8000 initialized ok.
Target initialized ok.
pdebug initialized
TargetDisconnect
TargetEnv: Clearing Environment
TargetEnv: Clearing Arguments
Wrong endian.
ResponseErr err=22
TargetDisconnect
TargetEnv: Clearing Environment
TargetEnv: Clearing Arguments
TargetConnect major=0 minor=1
ResponseOkStatus status=1056
-------------- host ----------------
ntosh-gdb
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for
details.
This GDB was configured as “–host=x86-pc-nto-qnx --target=ntosh”.
(gdb) target qnx 192.168.0.44:8000
Remote debugging using 192.168.0.44:8000
??? There is no prompt for the next procedure. Maybe it is pending …
What is your host? (Win, Sol or RTP), What version/release is it?
Our host is RTP 6.1(patch A).
What type of SH4 board are you using?
We are using the Solutions Engine board for SH4.
Can you ping your target from host?
Yes.
The released version of network driver which is located
at embedding direcotry for SE did not worked.
So, we have got the latest network driver for SE from QSSL Support Group
later.
It works very well now.
Byoung-Hweh Huh <purunsan@orgio.net> wrote:
“Tools Mail Account” <> tools@qnx.com> > wrote in message
news:a14itj$sed$> 1@nntp.qnx.com> …
Byoung-Hweh Huh <> purunsan@orgio.net> > wrote:
Hi,
Hello,
As you see following example, we can not debug remotely with target
system.
We can see that the gdb program is in the received-blocking mode
with io-net from pidin.
I guess the “pdebug” for SH4 platform has a bug from showing “Wrong
endian”.
It is not a bug, after it detects wrong one it displays it and then
reconnects with the proper one.
Please let me know how to configure the correct endian in “pdebug” and
solve
it.
---------------- target SH4 ----------------
ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4): 56 data bytes
64 bytes from 192.168.0.4: icmp_seq=0 ttl=255 time=1 ms
64 bytes from 192.168.0.4: icmp_seq=1 ttl=255 time=1 ms
…
export PDEBUG_DEBUG=1
pdebug 8000 &
20488 running pdebug
This version of pdebug was built on Jun 22 2001.
ProtoVer 0.1
Com port 8000 initialized ok.
Target initialized ok.
pdebug initialized
TargetDisconnect
TargetEnv: Clearing Environment
TargetEnv: Clearing Arguments
Wrong endian.
ResponseErr err=22
TargetDisconnect
TargetEnv: Clearing Environment
TargetEnv: Clearing Arguments
TargetConnect major=0 minor=1
ResponseOkStatus status=1056
-------------- host ----------------
ntosh-gdb
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for
details.
This GDB was configured as “–host=x86-pc-nto-qnx --target=ntosh”.
(gdb) target qnx 192.168.0.44:8000
Remote debugging using 192.168.0.44:8000
??? There is no prompt for the next procedure. Maybe it is pending …
What is your host? (Win, Sol or RTP), What version/release is it?
Our host is RTP 6.1(patch A).
What type of SH4 board are you using?
We are using the Solutions Engine board for SH4.
Can you ping your target from host?
Yes.
The released version of network driver which is located
at embedding direcotry for SE did not worked.
So, we have got the latest network driver for SE from QSSL Support Group
later.
It works very well now.
What works very well the driver or both the driver and gdb/pdebug session?
Regards,
Marcin
As you see following example, we can not debug remotely with target
system.
We can see that the gdb program is in the received-blocking mode
with io-net from pidin.
I guess the “pdebug” for SH4 platform has a bug from showing “Wrong
endian”.
It is not a bug, after it detects wrong one it displays it and then
reconnects with the proper one.
Our host is RTP 6.1(patch A).
What type of SH4 board are you using?
We are using the Solutions Engine board for SH4.
Can you ping your target from host?
Yes.
The released version of network driver which is located
at embedding direcotry for SE did not worked.
So, we have got the latest network driver for SE from QSSL Support Group
later.
It works very well now.
What works very well the driver or both the driver and gdb/pdebug session?
In the SE board, we can test only ‘ping’ successfully with the latest
network driver from QSSL
but the other port service of tcp would not work for example ‘ftp’, ‘telnet’
and so on.
I guess the network driver for SH4 and tcp socket program have some
problems.
Regards,
Marcin
Byoung-Hweh Huh <purunsan@orgio.net> wrote:
As you see following example, we can not debug remotely with target
system.
We can see that the gdb program is in the received-blocking mode
with io-net from pidin.
I guess the “pdebug” for SH4 platform has a bug from showing “Wrong
endian”.
It is not a bug, after it detects wrong one it displays it and then
reconnects with the proper one.
Our host is RTP 6.1(patch A).
What type of SH4 board are you using?
We are using the Solutions Engine board for SH4.
Can you ping your target from host?
Yes.
The released version of network driver which is located
at embedding direcotry for SE did not worked.
So, we have got the latest network driver for SE from QSSL Support Group
later.
It works very well now.
What works very well the driver or both the driver and gdb/pdebug session?
In the SE board, we can test only ‘ping’ successfully with the latest
network driver from QSSL
but the other port service of tcp would not work for example ‘ftp’, ‘telnet’
and so on.
I guess the network driver for SH4 and tcp socket program have some
problems.
Can you send me your build file to my tools@qnx.com email account, and Who
did give you the latest network driver?
Regards,
Marcin
Regards,
Marcin