Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-debug-dev] Using Eclipse for remote debugging

> 
> Finally I've fully operational Embedded/Remote IDE. Eclipse/CDT work  
> now with a cross  GNU tool chain (sparc-elf) on a Linux and Windows  
> host. The debugging is done with (sparc-elf) gdb 5.3.
> 

Very cool!!!

> 
> The following are my considerations/feedback:
> 
>     - shared library should be an option. On the last head CDT tolerates 
> now an error returned by gdb when "set-auto-solib-add on" is executed. 
> This is a good work around.

Yes, probably need more thoughts on this.

>     - thread support should also be an option. There are a lot of 
> embedded targets which don't supports threads (sparc-elf,...).  This is 
> not a serious problem, it simple causes
>         errors on gdb console at each execution step (and slows 
> therefore down the debugging).

The debugger view of the world:
Target
	Threads[]
		StackFrames[]
			Variables[]

A dummy thread is created when "info threads" return nothing.
Maybe, we can come up with a preference/button to enable disable
the call of "info threads".

"info threads" is call at every step, since gdb does not tell when
when a new thread is created or destroyed.

This goes for shared libs etc ..  The debugger goes to a certain
sequence of steps when suspended:

- list threads
	* compute update threads
- list stackframes
	* compute update stackframes
- list variables
	* compute update variables

It is time consuming, since everything is polled.

>    -  org.eclipse.cdt.debug.mi.core_1.0.1/plugin.xml should now be 
> modified manually to support not native debugging.
> 
> The debugging speed is 5 to 8 time faster on a windows machine than on a 
> Linux/motive machine.

Eclipse rocks on windows, I know I use to be on Eclipse/Solaris 8-).
But to be fair Eclipse-2.1 improved things a lot on Solaris and other non-windows.




Back to the top