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.
