Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-debug-dev] Re: cdt-debug-dev digest, Vol 1 #296 - 3 msgs

> -----Original Message-----
> From: cdt-debug-dev-admin@xxxxxxxxxxx 
> [mailto:cdt-debug-dev-admin@xxxxxxxxxxx] On Behalf Of Øyvind Harboe
> Sent: November 25, 2004 12:21 PM
> To: cdt-debug-dev@xxxxxxxxxxx
> Subject: [cdt-debug-dev] Re: cdt-debug-dev digest, Vol 1 #296 - 3 msgs
> 
> > Does it mean we replace gdb/Insight as your number #1 debugger ?
> 
> Not yet.
> 
> Insight is very much still in the game. 
> 
> Mainly it scores over CDT when dealing with runtime libraries 
> that are compiled outside Eclipse projects and highly 
> optimised code(basically CDT trusts the information it is 
> served from GDB + debug info too much).
> In my case that's mainly eCos OS + STLport. 

[ Other cases of Insight winning over CDT snipped ]

I'm not sure I understand this point.  The first aspect, the 
runtime libraries compiled outside of Eclipse, should be easily 
solved if you had a project that contained the matching source.
Then when the source isn't found the source locator would kick
in and you would specify the source location.  Does this not 
happen in your case?

The second aspect, the CDT trusting gdb/debug info too much,
I'm not sure how Insight deals with any different then CDT does.
If you could provide examples and/or insight (pun intended) on
this issue that would be great.  Even if it doesn't get fixed
right away, at least we can understand it better.

Thanks,
 Thomas


Back to the top