Problem with BP's

[Rainer Schuetze via Digitalmars-d-debugger]

On 18.08.2017 02:05, Johnson Jones wrote:
> On Friday, 18 August 2017 at 00:02:23 UTC, Johnson Jones wrote:
>> On Thursday, 17 August 2017 at 22:41:51 UTC, Johnson Jones wrote:
>>> I was doing something strange ;/
>>>
>>> I had code like
>>>
>>> mixin(import("Myfile.d"));
>>> CallSomeFunctionInMyFile();
>>>
>>> And no BP's could be hit in side the function call. D would say that 
>>> there was an error in the symbols for the project.
>>>
>>>
>>> but making MyFile.d a module(adding module MyFile; at the top) and doing
>>>
>>> import Myfile;
>>> CallSomeFunctionInMyFile();
>>>
>>> Allowed the breakpoints to be hit.
>>>
>>> I guess this is a related problem with mixin debugging, which still 
>>> doesn't work for me. In a sense, it might be a good why to debug them 
>>> because the file exists already and one doesn't have to have it 
>>> generated by the compiler to debug. This should help get the symbols 
>>> and line numbers correct and the line mappings. Might help make a 
>>> seemless way to debug them. e.g., any BP's in Myfile.d have to be 
>>> translated to the original file they are mixed in at and vice versa 
>>> when debugging them(open Myfile D).
>>
>> Hmm, maybe that wasn't the fix, still getting the error in some cases:
>>
>> The error is "Unexpected symbol reader error while processing test.exe"
>>
>> It might have been coincidence that the above change worked or it 
>> might be that it only partially fixed it.
> 
> What's strange about it is that delegates inside the function I'm 
> calling are hit but code in the root of the function are not.
> 
> void CallSomeFunctionInMyFile()
> {
>     addDelegate(()
>     {
>        foo();
>     });
> 
>     foo();
> }
> 
> The first foo will break on a BP assinged to it but the second one won't.
> 

You can try switching to the disassembly view to see where the compiler 
generated debug line numbers.

It assumes line numbers and code offsets are always ascending. Maybe 
assumption doesn't hold here.