digitalmars.D.debugger - Problem with BP's
- Johnson Jones (19/19) Aug 17 2017 I was doing something strange ;/
- Johnson Jones (7/27) Aug 17 2017 Hmm, maybe that wasn't the fix, still getting the error in some
- Johnson Jones (13/49) Aug 17 2017 What's strange about it is that delegates inside the function I'm
- Rainer Schuetze (5/56) Aug 17 2017 You can try switching to the disassembly view to see where the compiler
- Rainer Schuetze (4/31) Aug 17 2017 debugging mixins is not really supported by the compiler. It generates
- Johnson Jones (26/39) Aug 20 2017 Yes, but in this case, it does exist! Which is why I'm saying it
- Rainer Schuetze (4/62) Aug 20 2017 There have been a couple of implementations of this, e.g.
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
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
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: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.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
On 18.08.2017 02:05, Johnson Jones wrote:On Friday, 18 August 2017 at 00:02:23 UTC, Johnson Jones wrote: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 Thursday, 17 August 2017 at 22:41:51 UTC, Johnson Jones wrote: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.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
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
On Friday, 18 August 2017 at 06:43:37 UTC, Rainer Schuetze wrote:On 18.08.2017 00:41, Johnson Jones wrote: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.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.
Aug 20 2017
On 20.08.2017 20:26, Johnson Jones wrote:On Friday, 18 August 2017 at 06:43:37 UTC, Rainer Schuetze wrote: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.On 18.08.2017 00:41, Johnson Jones wrote: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.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.
Aug 20 2017