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).

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.

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.

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).
> 

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.

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.

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.