www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - visual D BP's not being hit

reply Amex <Amex gmail.com> writes:
I'm trying to put a break point in the code.

		if (index < 0 || index >= S.length)
		{
			return;
			return;
			return;
			return;
		}

I've added BP's to every return and even added some code such as 
asm {int 3; }

The BP's show up when not debugging but when I enter debug they 
all get moved to below the last }(I guess the first line of code 
after }) and break on that piece and not in the check.

I've notice similar issue before like this where BP's act funky. 
I can't simplify the code because it mostly doesn't behave this 
way and is quite random(and the code is very complex.

It seems there is some issue with the source code mapping.

Even if I just do

		if (index < 0 || index >= S.length)
			return;

and put a BP on the return then my code breaks at the line below 
it.

Maybe what you could to is take some fairly complex code(at least 
a 1000's lines and put BP's everywhere and try to find ones that 
are not working correctly.

This may be an issue only with the Visual Studio mixed mode 
debugger as I just switched to it from mago and I don't remember 
having many problems like this with mago. I just switched and 
same problem though.

In VS it reports the right line number when the BP is highlighted 
but in code it is not(67 but then becomes 69).


Using pretty much latest of everything and in VS2019.
Jun 02 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 02/06/2019 09:55, Amex wrote:
 It seems there is some issue with the source code mapping.
 
 Even if I just do
 
         if (index < 0 || index >= S.length)
             return;
 
 and put a BP on the return then my code breaks at the line below it.
 
That's a known issue with the dmd backend: it doesn't generate any code that could be identified with the return statement, because the respective jump instruction is already generated into the condition. Walter thinks these kind of optimizations are necessary even in debug builds, so that it still runs reasonably fast. I'm not so sure... Workaround is adding some code to the return block statement that isn't/cannot be removed.
Jun 02 2019
parent Amex <Amex gmail.com> writes:
On Sunday, 2 June 2019 at 09:47:27 UTC, Rainer Schuetze wrote:
 On 02/06/2019 09:55, Amex wrote:
 It seems there is some issue with the source code mapping.
 
 Even if I just do
 
         if (index < 0 || index >= S.length)
             return;
 
 and put a BP on the return then my code breaks at the line 
 below it.
 
That's a known issue with the dmd backend: it doesn't generate any code that could be identified with the return statement, because the respective jump instruction is already generated into the condition. Walter thinks these kind of optimizations are necessary even in debug builds, so that it still runs reasonably fast. I'm not so sure... Workaround is adding some code to the return block statement that isn't/cannot be removed.
Wow, Why not just make it optional? A simple command line option. I don't see how it could significantly slow things down and the whole point of debugging is to debug. It's very weird for a BP too jump to a line outside the scope ;/ Requiring junk code just to make it work is unacceptable(it takes more time to write and delete than all the overhead in the returns in the program would add and must be done every time). Maybe you should talk Walter in to getting a VisualD version flag added to the DMD compiler so that one could compile with it and get VisualD specific code emitted? Such code could be added willy nilly(not requiring dips since they do not effect standard operation) and be used to improve coding under VisualD.
Jun 02 2019