Project Home
Project Home		 Source Code
Source Code		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Core Development Tools/Discussion/General/Better debugging/List of Posts
BroadcastCommunity.qnx.com will be offline from May 31 6:00pm until June 2 12:00AM for upcoming system upgrades. For more information please go to https://community.qnx.com/sf/discussion/do/listPosts/projects.bazaar/discussion.bazaar.topc28418
Forum Topic - Better debugging: (5 Items)
   
Update
David Reynolds(deleted)
09/27/2010 9:09 PM
post68716
Better debugging   
Hello,

I am very interested in being able to debug programs that use the STL. As you know the symbolic debugging with the QNX 
tools just shows the implementation of the container and not the contents.

I see experimental support for CDT 7.0- which includes support for GDB 7.x- which includes support for pretty printing. 
This begs the question: Is there a GDB 7.x on the horizon for us?

Also, it seems to me if QNX just provided a native (target) gdbserver, then this would avoid the trouble of maintaining 
GDB for all of the host platforms, QNX would just need to maintain gdbserver and we could just use an existing GDB that 
runs native on the host (which are easy to come by for Linux and Windows). This has the added benefit that other 
debuggers could be used (like the SlickEdit Debugger, Insight, and even Eclipse/CDT) without any support from QNX needed
! This would allow us to get our hands on new features quicker (like CDT7)- sounds like a win-win. Any thoughts?
Aleksandar Ristovski(deleted)
09/27/2010 11:38 PM
post68719
Re: Better debugging   
On Mon, 2010-09-27 at 21:09 -0400, David Reynolds wrote:
> Hello,
> 
> I am very interested in being able to debug programs that use the STL. As you know the symbolic debugging with the QNX
 tools just shows the implementation of the container and not the contents.
> 
> I see experimental support for CDT 7.0- which includes support for GDB 7.x- which includes support for pretty printing
. This begs the question: Is there a GDB 7.x on the horizon for us?

Yes there is, but I can not give you any date at this moment.

> 
> Also, it seems to me if QNX just provided a native (target) gdbserver, then this would avoid the trouble of 
maintaining GDB for all of the host platforms

It is not exactly that easy. Gdb configured for your linux machine is
not necessarily  configured to support qnx target, and there are
portions of changes that are not in sync with FSF.

In any case, we can not avoid maintaining gdb (if we switched to
gdbserver instead of our equivalent pdebug, we would have to maintain
both).

BTW, there is gdbserver for x86 nto target which you could build from
FSF gdb sources, but you will still need gdb configured for qnx target
on your host.


---
Aleksandar
David Reynolds(deleted)
09/28/2010 9:28 AM
post68756
RE: Better debugging   
Aleksandar,

Thanks for the reply.

I did build gdbserver for x86 nto, but it did not work well. I tried 3 or 4 different versions of GDB (including the one
 supplied by QNX) and they all did the same thing- after stopping and restarting the target, the target would not stop 
again. So the 1st time a breakpoint was hit would be the only time.

I admit I didn't look too close- I assumed that the gdb-gdbserver protocol was abstract enough to allow it to work 
without GDB knowing too much about the target.

Oh well it looks like I'll have to wait for ntox86-gdb 7.x to come out.

Thanks again.

Dave.


-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com] 
Sent: Monday, September 27, 2010 11:39 PM
To: general-toolchain
Subject: Re: Better debugging

On Mon, 2010-09-27 at 21:09 -0400, David Reynolds wrote:
> Hello,
> 
> I am very interested in being able to debug programs that use the STL. As you know the symbolic debugging with the QNX
 tools just shows the implementation of the container and not the contents.
> 
> I see experimental support for CDT 7.0- which includes support for GDB 7.x- which includes support for pretty printing
. This begs the question: Is there a GDB 7.x on the horizon for us?

Yes there is, but I can not give you any date at this moment.

> 
> Also, it seems to me if QNX just provided a native (target) gdbserver, then this would avoid the trouble of 
maintaining GDB for all of the host platforms

It is not exactly that easy. Gdb configured for your linux machine is
not necessarily  configured to support qnx target, and there are
portions of changes that are not in sync with FSF.

In any case, we can not avoid maintaining gdb (if we switched to
gdbserver instead of our equivalent pdebug, we would have to maintain
both).

BTW, there is gdbserver for x86 nto target which you could build from
FSF gdb sources, but you will still need gdb configured for qnx target
on your host.


---
Aleksandar




_______________________________________________

General
http://community.qnx.com/sf/go/post68719
Aleksandar Ristovski(deleted)
09/28/2010 9:47 AM
post68766
RE: Better debugging   
The issue you are seeing is clearly a bug, that much should work. Which
sources did you use for building gdbserver?

Note that we are not actively maintaining gdbserver since we have
conceptual equivalent called pdebug which is "our own". IDE uses some of
the special qnx gdb commands, so if you want full debugging comfort, you
really need qnx-supplied IDE and gdb.

I will try to make a (very) experimental gdb 7.2 available forg playing
(but it won't be sooner than in a few weeks).

Meanwhile, for pretty-printing your container values, as a (inadequate)
workaround you can define a function in your code that will print
container in question. Then when stopped, you can call it from gdb (not
that it can compare, but it may help move forward).

Thanks,

Aleksandar
David Reynolds(deleted)
09/28/2010 10:14 AM
post68776
RE: Better debugging   
Aleksandar,

Yeah I have GDB macros for all containers, which I invoke in the GDB command window while debugging, but this does not 
help too much- it really only works well when a container contains a POD type (which is almost never). But I do at least
 get a count.

As far as building gdbserver, I pulled right from FSF's CVS (version 7.1 I think) and built it native on QNX (configure/
make). It built with no trouble; I did not have to muck with anything. If nobody is maintaining this then I'd rather not
 use it anyway.

When you have an experimental GDB 7.x please post to the project wiki and I'll try it out (I'm using windows as a host).


Thanks again,

Dave.

-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com] 
Sent: Tuesday, September 28, 2010 9:48 AM
To: general-toolchain
Subject: RE: Better debugging

The issue you are seeing is clearly a bug, that much should work. Which
sources did you use for building gdbserver?

Note that we are not actively maintaining gdbserver since we have
conceptual equivalent called pdebug which is "our own". IDE uses some of
the special qnx gdb commands, so if you want full debugging comfort, you
really need qnx-supplied IDE and gdb.

I will try to make a (very) experimental gdb 7.2 available forg playing
(but it won't be sooner than in a few weeks).

Meanwhile, for pretty-printing your container values, as a (inadequate)
workaround you can define a function in your code that will print
container in question. Then when stopped, you can call it from gdb (not
that it can compare, but it may help move forward).

Thanks,

Aleksandar






_______________________________________________

General
http://community.qnx.com/sf/go/post68766

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems