Thread overview
visual D BP's not being hit
Jun 02, 2019
Amex
Jun 02, 2019
Rainer Schuetze
Jun 02, 2019
Amex
June 02, 2019
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.



June 02, 2019

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.
June 02, 2019
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.