www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - Problem with BP's

reply Johnson Jones <JJ Dynomite.com> writes:
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).
Aug 17 2017
next sibling parent reply Johnson Jones <JJ Dynomite.com> writes:
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.
Aug 17 2017
parent reply Johnson Jones <JJ Dynomite.com> writes:
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.
Aug 17 2017
parent Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Aug 17 2017
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 18.08.2017 00:41, 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.
 


debugging mixins is not really supported by the compiler. It generates 
source filenames that don't exist.


 
 but making MyFile.d a module(adding module MyFile; at the top) and doing
 
 import Myfile;
 CallSomeFunctionInMyFile();
 
 Allowed the breakpoints to be hit.


That would the normal usage, too.


 
 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).
Aug 17 2017
parent reply Johnson Jones <JJ Dynomite.com> writes:
On Friday, 18 August 2017 at 06:43:37 UTC, Rainer Schuetze wrote:

 On 18.08.2017 00:41, 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.
 


 debugging mixins is not really supported by the compiler. It 
 generates source filenames that don't exist.


Yes, but in this case, it does exist! Which is why I'm saying it 
might be a useful feature!

mixin(import(filename))

is essentially a direct insertion of filename in to the D source.

Even though it internally goes through the mixin analysis of the 
code, it passes right through.

So, If VisualD knew that, it could just link up filename in to 
the source and allow debugging of it.

If dmd outputted all string mixins to files, then the same logic 
would apply.

e.g.,

it would rewrite

mixin("Hello World");

to

mixin(import(temp342.d));

and temp342.d would contain "Hello World".

Or it could just create a special module for it then import that 
directly like below, which would probably allow it to nearly work 
with Visual D. Visual D would just then have to know what is 
going on so it could dive in to the "sub-file".


What I'm getting at is that it seems like very little work would 
have to be done to get string mixins to be debuggable... instead 
of trying to write some specialized mixin debugger. Dmd and 
Visual D already do all the heavy lifting, they just need to 
communicate with each other enough to make it happen.
Aug 20 2017
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 20.08.2017 20:26, Johnson Jones wrote:

 On Friday, 18 August 2017 at 06:43:37 UTC, Rainer Schuetze wrote:

 On 18.08.2017 00:41, 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.


 debugging mixins is not really supported by the compiler. It generates 
 source filenames that don't exist.


 
 Yes, but in this case, it does exist! Which is why I'm saying it might 
 be a useful feature!
 
 mixin(import(filename))
 
 is essentially a direct insertion of filename in to the D source.
 
 Even though it internally goes through the mixin analysis of the code, 
 it passes right through.
 
 So, If VisualD knew that, it could just link up filename in to the 
 source and allow debugging of it.
 
 If dmd outputted all string mixins to files, then the same logic would 
 apply.
 
 e.g.,
 
 it would rewrite
 
 mixin("Hello World");
 
 to
 
 mixin(import(temp342.d));
 
 and temp342.d would contain "Hello World".
 
 Or it could just create a special module for it then import that 
 directly like below, which would probably allow it to nearly work with 
 Visual D. Visual D would just then have to know what is going on so it 
 could dive in to the "sub-file".
 
 
 What I'm getting at is that it seems like very little work would have to 
 be done to get string mixins to be debuggable... instead of trying to 
 write some specialized mixin debugger. Dmd and Visual D already do all 
 the heavy lifting, they just need to communicate with each other enough 
 to make it happen.
 


There have been a couple of implementations of this, e.g. 
https://github.com/dlang/dmd/pull/426 and the patch in 
https://issues.dlang.org/show_bug.cgi?id=5051, but didn't get merged.
Aug 20 2017