• Amex (32/32) Jun 02 2019 I'm trying to put a break point in the code.
• Rainer Schuetze (8/17) Jun 02 2019 That's a known issue with the dmd backend: it doesn't generate any code
• Amex (14/34) Jun 02 2019 Wow, Why not just make it optional? A simple command line option.

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.

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.

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.