Re: [cdt-dev] Debugging 2 programs with single CDT instance

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> 647,797 43-break-insert --thread-group i1 main.c:76

Strange.  There should be a -f option above, like this:

544,575 35-break-insert --thread-group i1 -f Producer.cpp:157

Are you using the class CommandFactory_6_8?
That is where that option is set.


________________________________

	From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Derek Morris
	Sent: Friday, August 09, 2013 8:37 AM
	To: CDT General developers list.
	Subject: Re: [cdt-dev] Debugging 2 programs with single CDT instance
	
	

	On 9 Aug 2013, at 13:30, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:



			-----Original Message-----
			From: cdt-dev-bounces@xxxxxxxxxxx 
			[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Derek Morris
			Sent: Friday, August 09, 2013 8:16 AM
			To: CDT General developers list.
			Subject: [cdt-dev] Debugging 2 programs with single CDT instance
			
			Hi,
			
			I am trying to debug two independent (but communicating) 
			applications from a single instance of CDT.
			
			Everything works OK, except when setting a breakpoint.
			
			When setting a breakpoint in a source file, CDT attempts to 
			set the breakpoint in both Debug sessions, which leads to a 
			warning be displayed "Breakpoint attribute problem: 
			installation failed".
			


		GDB now sets a breakpoint as pending whenever it cannot
		set it, so I wouldn't expect you to see such an error.
		Are you using an older GDB (< 7.0)?
		

	GDB 7.3.1

	This is what gdbtraces reports in the 'wrong' debug session:
	647,797 43-break-insert --thread-group i1 main.c:76
	647,797 43^error,msg="No source file named main.c."
	647,797 (gdb) 


			I understand that you cannot tell which debug session is 
			appropriate to set the breakpoint and therefore need to try 
			both, but it would be good to be able to filter the error, so 
			that if a breakpoint was set *somewhere* then no error would 
			be reported.
			
			Does anybody have a suggestion where I should look to try to 
			implement this functionality?
			


		MIBreakpointsManager.installBreakpoint()
		In there, you will see a handleError() overridden method.  That
		is where the error gets set.
		I guess you could check if the install count is greater than 0
		and not set the error.
		
		

	I'll take a look.
	

		You'll also have to clear such an error if the breakpoint gets
		successfully planted after an error was reported.
		
		I haven't thought about it in-depth, but your idea sounds
		like a interesting approach.
		
		thanks!
		

	thanks!
	


		marc
		
		


			Thanks
			
			_______________________________________________
			cdt-dev mailing list
			cdt-dev@xxxxxxxxxxx
			https://dev.eclipse.org/mailman/listinfo/cdt-dev
			
			

		_______________________________________________
		cdt-dev mailing list
		cdt-dev@xxxxxxxxxxx
		https://dev.eclipse.org/mailman/listinfo/cdt-dev