Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ TheIDE » U++ TheIDE: Other Features Wishlist and/or Bugs » Conditional breakpoints
Conditional breakpoints [message #30119] Thu, 09 December 2010 20:42 Go to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

Hi everyone,

Today, I finally got angry enough to start implementing one of the features I seriously miss in theide: conditional breakpoints. I guess most of you knows the frustration when you know that the bug is probably in the last iteration of 1000 cycles loop and you just can't tell the debugger to stop when i=999 Smile

So I started digging into the code and to my great surprise, I found out that the code is already there, just commented out! Shocked Mirek, why are you hiding such a powerful feature from us?! Smile

Then I tried to uncomment it (ide/idebar.cpp:480) to see if it really works... well it didn't but the fix is actually trivial, just change Gdb::SetBreakpoint() in Gdb.cpp to:
bool Gdb::SetBreakpoint(const String& filename, int line, const String& bp)
{
	String bi = Bpoint(*host, filename, line);
	if(bp.IsEmpty())
		FastCmd("clear " + bi);
	else if(bp[0]==0xe)
		FastCmd("b " + bi);
	else
		FastCmd("b " + bi + " if " + bp);
	return true;
}


Now the conditional breakpoints work perfectly (with gdb). I am not sure what will happen with MSVC installs (I don't have any to test - help wanted Wink ), but I believe it will just ignore the condition, so it should not cause any trouble. If anyone decides to fix this for windows users too I can just point you to this page where you can find some possibly usefull info about msdev syntax.

Is it OK to commit this in current state? Or should I wait till someone writes the M$ part?

Best regards,
Honza
Re: Conditional breakpoints [message #30331 is a reply to message #30119] Sat, 25 December 2010 00:06 Go to previous messageGo to next message
alendar is currently offline  alendar
Messages: 47
Registered: January 2010
Location: Idaho, USA
Member
This looks like a cool feature. I'd love to try it if it gets deployed. I use both the Windows and linux versions.

cd7651feeb698f6ac6cec1f6deda5e5b
Re: Conditional breakpoints [message #30559 is a reply to message #30119] Sat, 08 January 2011 13:50 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
dolik.rce wrote on Thu, 09 December 2010 14:42

Hi everyone,

Today, I finally got angry enough to start implementing one of the features I seriously miss in theide: conditional breakpoints. I guess most of you knows the frustration when you know that the bug is probably in the last iteration of 1000 cycles loop and you just can't tell the debugger to stop when i=999 Smile

So I started digging into the code and to my great surprise, I found out that the code is already there, just commented out! Shocked Mirek, why are you hiding such a powerful feature from us?! Smile

Then I tried to uncomment it (ide/idebar.cpp:480) to see if it really works... well it didn't but the fix is actually trivial, just change Gdb::SetBreakpoint() in Gdb.cpp to:
bool Gdb::SetBreakpoint(const String& filename, int line, const String& bp)
{
	String bi = Bpoint(*host, filename, line);
	if(bp.IsEmpty())
		FastCmd("clear " + bi);
	else if(bp[0]==0xe)
		FastCmd("b " + bi);
	else
		FastCmd("b " + bi + " if " + bp);
	return true;
}


Now the conditional breakpoints work perfectly (with gdb). I am not sure what will happen with MSVC installs (I don't have any to test - help wanted Wink ), but I believe it will just ignore the condition, so it should not cause any trouble. If anyone decides to fix this for windows users too I can just point you to this page where you can find some possibly usefull info about msdev syntax.

Is it OK to commit this in current state? Or should I wait till someone writes the M$ part?

Best regards,
Honza


Please commit.

I do not remember the exact issue why it is commented out...

Mirek
Re: Conditional breakpoints [message #30561 is a reply to message #30559] Sat, 08 January 2011 17:49 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

mirek wrote on Sat, 08 January 2011 13:50


Please commit.

I do not remember the exact issue why it is commented out...

Mirek

OK, committed. I tested with MSVC as well, to make sure there is no problem with it (yep, finally installed it in wine Smile ) Unfortunately the debugging under wine doesn't work properly... But from what I saw it appears that the breakpoints set as conditional are treated just like normal ones. I will try to investigate bit further, maybe I'll find out how to make it work.

Honza
Re: Conditional breakpoints [message #30562 is a reply to message #30561] Sat, 08 January 2011 19:54 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
dolik.rce wrote on Sat, 08 January 2011 11:49

mirek wrote on Sat, 08 January 2011 13:50


Please commit.

I do not remember the exact issue why it is commented out...

Mirek

OK, committed. I tested with MSVC as well, to make sure there is no problem with it (yep, finally installed it in wine Smile ) Unfortunately the debugging under wine doesn't work properly... But from what I saw it appears that the breakpoints set as conditional are treated just like normal ones. I will try to investigate bit further, maybe I'll find out how to make it work.

Honza


Ah, that is the issue Smile We cannot do this in MSC, so I have commented it out, because MSC is IMO more important...

OK, please, would it be possible to make it debugger dependent?

(Or, of course, if you would like to add conditionals to MSC, that would be a nice solution as well Wink
Re: Conditional breakpoints [message #30565 is a reply to message #30562] Sat, 08 January 2011 20:52 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

mirek wrote on Sat, 08 January 2011 19:54

Or, of course, if you would like to add conditionals to MSC, that would be a nice solution as well Wink

I would like to do that, but first I have to make MSC debugging work in wine... (Because I'm not going to install windows just because of this Smile )

Making the feature debugger dependent is not really simple. Mainly because behavior when user switches build methods would be hard to implement in any logical way (should the breakpoints disappear, lose the condition or what?).

BTW: While looking around I found few weird places in the debugging code, e.g. if you compile theide with mingw, it can't use Pdb debugger. I will post or commit fixes for this as well...

Honza
Re: Conditional breakpoints [message #30569 is a reply to message #30119] Sun, 09 January 2011 13:52 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

I have had a closer look at the Pdb class and related parts of theide and I have to confess that I am seriously confused. At first look, it appears that theide implements it's own debugger. Looking e.g. in Pdb::AddBp(), I see that to add breakpoint theide directly changes the memory of the debugged process. Also the huge size of Pdb class code (compared to Gdb) hints that it is way more complicated.

Mirek, could you give me a quick overview about how this beast works? Just a few sentences about the design and hint where to look at start would be fine. Also, if my idea about how this works is correct, could you tell me why doesn't theide use e.g. cdb.exe, that comes with the SDK, in similar manner as gdb is used? It seems to be much simpler at first glance, so there must be some serious reason...

Honza
Re: Conditional breakpoints [message #30570 is a reply to message #30569] Sun, 09 January 2011 15:00 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
dolik.rce wrote on Sun, 09 January 2011 07:52

I have had a closer look at the Pdb class and related parts of theide and I have to confess that I am seriously confused. At first look, it appears that theide implements it's own debugger.



Yes.

Quote:


Mirek, could you give me a quick overview about how this beast works? Just a few sentences about the design and hint where to look at start would be fine.



Well, there is a M$ supplied dbghelp.dll file that provides functions to extract symbolic debug info from .exe.

Then there is Win32 debugging API.

The rest is me Smile

Quote:


Also, if my idea about how this works is correct, could you tell me why doesn't theide use e.g. cdb.exe, that comes with the SDK, in similar manner as gdb is used? It seems to be much simpler at first glance, so there must be some serious reason...


Because cdb.exe is even more pain in the ass to work with than gdb.

This way, if nothing else, pdb debugger is fast and relatively reliable.

In fact, if I would have similar api to dbghelp.dll (or, more precisely, if I understood existing equivalents to it for posix), I would do posix debugging similar, avoiding gdb.
Re: Conditional breakpoints [message #30585 is a reply to message #30570] Mon, 10 January 2011 16:41 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

mirek wrote on Sun, 09 January 2011 15:00

At first look, it appears that theide implements it's own debugger.

Yes.[/quote]
Well, exactly what I was afraid of Smile Anyway, I read enough of the sources to figure out how to implement the conditional breakpoints. If all goes well there will be a very little code to add, since most of the needed functionality is already there. So the last problem that remains is that I have nowhere to test it Smile (The debugger refuses to work in wine Sad ) Looks like I will have to either install windows in emulator or install all the stuff on someone else's computer...

mirek wrote on Sun, 09 January 2011 15:00


Because cdb.exe is even more pain in the ass to work with than gdb.

This way, if nothing else, pdb debugger is fast and relatively reliable.

In fact, if I would have similar api to dbghelp.dll (or, more precisely, if I understood existing equivalents to it for posix), I would do posix debugging similar, avoiding gdb.

I see a major advantage of gdb in fact that it is already written Smile From my point of view, gdb is easy to use, has some really nice features and is installed on almost any computer. But I can't talk for cdb, I never used that. If you say it's pain to work with, I'll have to believe you Smile

Honza
Re: Conditional breakpoints [message #30588 is a reply to message #30585] Mon, 10 January 2011 17:58 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
dolik.rce wrote on Mon, 10 January 2011 10:41

From my point of view, gdb is easy to use, has some really nice features and is installed on almost any computer. But I can't talk for cdb, I never used that. If you say it's pain to work with, I'll have to believe you Smile



I have not said gdb is bad. It is just difficult to combine it with GUI frontend intended for C++ debugging.

E.g. one of issues is that if you query the value of any widget 'variable', you get about 1.5MB of text to parse...

Plus, all that pushing commands to gdb and parsing results, done via pipes, is extremely painful and quirky...

[Updated on: Mon, 10 January 2011 17:58]

Report message to a moderator

Re: Conditional breakpoints [message #30649 is a reply to message #30119] Thu, 13 January 2011 15:03 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

I finally got some time with windows computer, so I could test what I blind coded in past few days Smile

I extended the parser in Exp.cpp to allow comparisons, logical and bitwise operations. Hopefully with correct C++ priorities Smile Then I added a Vector to store the conditions and Pdb::ConditionCheck() function that check whether the condition for given breakpoint is fulfilled or not by evaluating it using Pdb::Exp() call. Up to here it appears to work quite well.

I hit a problem when I tried to "cancel" the breakpoints for which condition is not fulfilled in Pdb::RunToException(). The code looks like it should be enough to break instead of returning and wait for next breakpoint:
			switch(event.dwDebugEventCode) {
			case EXCEPTION_DEBUG_EVENT: {
// ...
				int bp=bp_set.Find((adr_t)event.u.Exception.ExceptionRecord.ExceptionAddress);
				if(event.u.Exception.ExceptionRecord.ExceptionCode == EXCEPTION_BREAKPOINT && bp >= 0)
					#ifdef CPU_32
					context.Eip = (adr_t)event.u.Exception.ExceptionRecord.ExceptionAddress;
					#else
					context.Rip = (adr_t)event.u.Exception.ExceptionRecord.ExceptionAddress;
					#endif

				RemoveBp();
				LLOG("Exception: " << FormatIntHex(event.u.Exception.ExceptionRecord.ExceptionCode) <<
				     " at: " << FormatIntHex(event.u.Exception.ExceptionRecord.ExceptionAddress) <<
				     " first: " << event.u.Exception.dwFirstChance);
				if(bp>=0 && !ConditionCheck(bp))
					break;     // condition doesn't fit - we don't want to stop at this breakpoint
				return true;       //the condition is true, we should stop
// ...
This however still stops at every breakpoint, regardless if it breaks or returns. Could you give me a hint how to do this properly, please?

Later, it would be also good idea to actually do the check before switching theide back to foreground etc., but that will probably require bigger changes. For now I'm just wondering how to skip the unfitting breakpoints.

Honza

PS: I attach all the changed sources, so you can test.

EDIT: Removed attachment, newer version available below.

[Updated on: Fri, 14 January 2011 17:46]

Report message to a moderator

Re: Conditional breakpoints [message #30651 is a reply to message #30649] Thu, 13 January 2011 15:32 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Have you tried to debug it? Smile

(Indeed, little is as amusing as debugging debugger, preferably in itself Smile
Re: Conditional breakpoints [message #30656 is a reply to message #30651] Fri, 14 January 2011 07:54 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

mirek wrote on Thu, 13 January 2011 15:32

Have you tried to debug it? Smile

(Indeed, little is as amusing as debugging debugger, preferably in itself Smile


I tried - it's hell of a confusing job to debug ide that is debugging another program Twisted Evil But I had limited time and couldn't get the hang of it quick enough :-/

Honza
Re: Conditional breakpoints [message #30658 is a reply to message #30119] Fri, 14 January 2011 13:28 Go to previous message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

So, I looked into bit more and get better understanding about how it works, but apparently still not good enough. I was able to correct few errors, so now it almost works. The only problem now is that the debugged program is terminated as soon as first unfulfiled condition is hit.

Unfortunately, I will be pretty busy next few days, so I won't be able to get back to this until after next week Sad If anyone wants to finish it sooner, I won't object Wink The sources are attached.

Honza
  • Attachment: Debuggers.zip
    (Size: 12.56KB, Downloaded 236 times)
Previous Topic: Docking for ToolBars
Next Topic: Split window
Goto Forum:
  


Current Time: Thu Mar 28 22:20:25 CET 2024

Total time taken to generate the page: 0.01744 seconds