|
Bill Highman
|
code::blocks and ntoppc-gdb and qconn
|
|
Bill Highman
08/24/2009 4:10 PM
post36577
|
code::blocks and ntoppc-gdb and qconn
code::blocks can be used as an editor and building tools. but debugger is hard to be set. Anyone has experiences? how is
ntoppc-gdb configured to talk to qconn? or other component also gets involved in eclipse.
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: code::blocks and ntoppc-gdb and qconn
|
|
Aleksandar Ristovski(deleted)
08/25/2009 9:46 AM
post36620
|
Re: code::blocks and ntoppc-gdb and qconn
I have never used code blocks, but by quick glance through
their wiki I see it is using gdb for debugging. Integration
should, therefore, have been done.
Make sure you point this IDE to our gdb. Instruct it to
connect to remote target using qnx protocol; depending on
how configurable it is, this may be difficult without
modifying the code.
An easy hack would be to specify "target qnx
<targetip>:<port>" in your .gdbinit file. In this scenario,
IDE should not make attempts to connect to remote target,
but rather work with the binary as if it was running locally.
Second point that may be tricky is how configurable IDE is
for uploading binary to the target; there are some options
here as well. If it doesn't know how to do that using ftp
and such, you can use shared directory (nfs or cifs). Or,
you can add upload command to your .gdbinit.
An example of .gdbinit file would be:
------
target qnx <targetip>:8000
upload <binaryonhost> <pathontarget/binaryname>
------
The rest should be taken care of by the IDE.
Hope this helps,
Aleksandar
Bill Highman wrote:
> code::blocks can be used as an editor and building tools. but debugger is hard to be set. Anyone has experiences? how
is ntoppc-gdb configured to talk to qconn? or other component also gets involved in eclipse.
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post36577
>
|
|
|
|
|
|
Bill Highman
|
Re: code::blocks and ntoppc-gdb and qconn
|
|
Bill Highman
08/26/2009 2:40 PM
post36734
|
Re: code::blocks and ntoppc-gdb and qconn
Thanks for the help.
I did try
- target qnx ip:8000
- upload localfile /tmp/targetfile
it works. But something wrong as well.
- use upload in my test, the target file cannot be updated while it is new built. (in another way, no "target qnx delete
" cmd :-)
But I found something interesting with Momentics. It seems not use upload in gdb to put the target binary to the target
directory like /tmp.
because when it connect to target using "-target-select ip:8000" and "attach xxxx", it means the target file has been
put there and pid is acquired by IDE. How does it do these? any code or document?
cheers
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: code::blocks and ntoppc-gdb and qconn
|
|
Aleksandar Ristovski(deleted)
08/26/2009 2:50 PM
post36735
|
Re: code::blocks and ntoppc-gdb and qconn
Bill Highman wrote:
> Thanks for the help.
>
> I did try
> - target qnx ip:8000
> - upload localfile /tmp/targetfile
>
> it works. But something wrong as well.
>
> - use upload in my test, the target file cannot be updated while it is new built. (in another way, no "target qnx
delete" cmd :-)
>
> But I found something interesting with Momentics. It seems not use upload in gdb to put the target binary to the
target directory like /tmp.
>
> because when it connect to target using "-target-select ip:8000" and "attach xxxx", it means the target file has been
put there and pid is acquired by IDE. How does it do these? any code or document?
Momentics uses qconn services which are not documented.
The easiest alternative is to use gdb as described
previously. The file should get overwritten when you do
upload again. To force .gdbinit read, IDE should start new
gdb session every time you want new file to get uploaded.
If you want to start inferior (this is debugee in gdb
parlance) and attach to it, you need to start it in "held"
state; this can be done by using command line utility "on"
on the target, like this:
# on -h myexe
Then you need to find its PID (e.g. pidin | grep myexe) and
finally to instruct gdb to use this PID to attach to it.
---
Aleksandar
|
|
|
|
|
|
Christian Damus(deleted)
|
Re: code::blocks and ntoppc-gdb and qconn
|
|
Christian Damus(deleted)
08/26/2009 2:53 PM
post36736
|
Re: code::blocks and ntoppc-gdb and qconn
Hi, Bill,
The Momentics IDE uses the qconn agent to upload your binaries, and it
automatically deletes them after the debug session (though you can opt
not to). Also, for shared target systems, the IDE by default will
mangle the binary name to ensure that it is unique on the target system.
It is a similar to how the Target Filesystem Navigator in the Momentics
IDE allows you to copy files to the target from your host system, edit
them in-place, etc.
The qconn agent also acts as a broker/relay between the
(Neutrino-specific) gdb client and the Neutrino pdebug process which
provides the gdbserver-like debug agent capability.
HTH,
Christian
On Wed, 2009-08-26 at 14:40 -0400, Bill Highman wrote:
> Thanks for the help.
>
> I did try
> - target qnx ip:8000
> - upload localfile /tmp/targetfile
>
> it works. But something wrong as well.
>
> - use upload in my test, the target file cannot be updated while it is new built. (in another way, no "target qnx
delete" cmd :-)
>
> But I found something interesting with Momentics. It seems not use upload in gdb to put the target binary to the
target directory like /tmp.
>
> because when it connect to target using "-target-select ip:8000" and "attach xxxx", it means the target file has been
put there and pid is acquired by IDE. How does it do these? any code or document?
>
> cheers
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post36734
>
________________________________________________________________________
Christian W. Damus
Software Developer, IDE Team
QNX Software Systems
|
|
|
|
|
|
Bill Highman
|
Re: code::blocks and ntoppc-gdb and qconn
|
|
Bill Highman
08/27/2009 6:33 AM
post36762
|
Re: code::blocks and ntoppc-gdb and qconn
Thanks, Christian.
You confirmed most we can observe and guess. qconn is absolutely the sole entry for the communication with IDE side.
That's what I tried to do, how to adapt to it in IDE/debugger side. (The motivation is to reproduce in CB what's done
with debugger in Momentics.)
Great, Aleksandar. You are talking to me one solution what I wonder. on! Really nice. I do not know it before. Just
wonder how it is HELD there for gdb attach.
However, I am sure Momentics does not use on way, or qconn invokes on, because no no in my target. :-) Fine, that's
again proving that qconn is powerful, containing this HELD-state invoking functionality.
The part in Momentics talking to qconn is not open, right? If they can exist in a command form like tftp/rcp/scp, and
rsh/ssh way, it will be also great. you call these these commands as interface in IDE or script or manually input to
talk to qconn to transfer files, to delete them, to held-state run the them.
Just like ntoppc-gdb can talk to qconn, though the other side is not conventional gdbserver.
cheers
Highman
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: code::blocks and ntoppc-gdb and qconn
|
|
Aleksandar Ristovski(deleted)
08/27/2009 8:59 AM
post36767
|
Re: code::blocks and ntoppc-gdb and qconn
Bill Highman wrote:
> Thanks, Christian.
>
> You confirmed most we can observe and guess. qconn is absolutely the sole entry for the communication with IDE side.
That's what I tried to do, how to adapt to it in IDE/debugger side. (The motivation is to reproduce in CB what's done
with debugger in Momentics.)
>
> Great, Aleksandar. You are talking to me one solution what I wonder. on! Really nice. I do not know it before. Just
wonder how it is HELD there for gdb attach.
You can include it in your target's image.
>
> However, I am sure Momentics does not use on way, or qconn invokes on, because no no in my target. :-) Fine, that's
again proving that qconn is powerful, containing this HELD-state invoking functionality.
'on' utility, just like qconn, and just like pdebug as well
as gdb when running on the target, spawns the inferior with
inheritance flag SPAWN_HOLD. See documentation for 'spawn'.
>
> The part in Momentics talking to qconn is not open, right? If they can exist in a command form like tftp/rcp/scp, and
rsh/ssh way, it will be also great. you call these these commands as interface in IDE or script or manually input to
talk to qconn to transfer files, to delete them, to held-state run the them.
IDE uses qconn for much more than spawning inferior; to
implement all that in a different IDE would be quite a big task.
However, for just running debug sessions, gdb provides
everything you need.
>
> Just like ntoppc-gdb can talk to qconn, though the other side is not conventional gdbserver.
our gdb uses "qnx" protocol which is different from gdb's
remote protocol. Real gdb's debug server is not qconn but
pdebug (qnx specific). Qconn spawns pdebug and then only
channels communication between gdb and pdebug.
To see this more clearly, you can use pdebug without qconn:
# pdebug 8010
and then from your host:
$ ntoppc-gdb
(gdb) target qnx <targetip>:8010
(gdb) upload ....
...
For all other functions like file copy/delete, I would
suggest trying with telnet/ftp functionality (hopefully your
IDE provides nice extensibility to add that).
---
Aleksandar
|
|
|
|
|
|
