www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - Breakpoint for EXE to DLL debugging in VisualD (all D)

reply frame <frame86 live.com> writes:
Some code of my framework is reused in my DLL too because it has 
it's own logic as a plugin system.

I want to seamlessly debug from EXE to DLL inspection by running 
the main application.

If I set a breakpoint for a method in the VS debugger it 
generates breakpoints for all method overloads for the main EXE 
and also sometimes for the DLL too - but in most cases only for 
the EXE.

The breakpoint will be hit if the function name matches the 
process, so it seems.

eg.:
```main.exe!mylib.func.get!bool.get(...)```
```some.dll!mylib.func.get!bool.get(...)```

I tried to manually insert the breakpoint as modified function 
name, but that doesn't work.
I tried to export the breakpoint xml data and edit it, but I am 
afraid I also need the correct function address to get this 
working.

The only way it works so far is when the debugger catches an 
error in loaded DLL and opens the right editor tab for it. If I 
set a breakpoint then it also generates breakpoints for functions 
in the DLL too.

Is there are way to select the loaded DLL when setting a 
breakpoint I don't know?
May 06 2021
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 06/05/2021 16:21, frame wrote:

 Some code of my framework is reused in my DLL too because it has it's
 own logic as a plugin system.
 
 I want to seamlessly debug from EXE to DLL inspection by running the
 main application.
 
 If I set a breakpoint for a method in the VS debugger it generates
 breakpoints for all method overloads for the main EXE and also sometimes
 for the DLL too - but in most cases only for the EXE.


I have tried to reproduce the issue with a simple pair of exe and DLL
sharing a template in a common module, but that worked as expected
(showing both function locations in the list of breakpoints).


 
 The breakpoint will be hit if the function name matches the process, so
 it seems.
 
 eg.:
 ```main.exe!mylib.func.get!bool.get(...)```
 ```some.dll!mylib.func.get!bool.get(...)```
 
 I tried to manually insert the breakpoint as modified function name, but
 that doesn't work.
 I tried to export the breakpoint xml data and edit it, but I am afraid I
 also need the correct function address to get this working.


The mago debug extensions deals with D expressions, but not breakpoint
locations. There seems to be an interface to support function name
resolution, but it is not implemented yet.


 
 The only way it works so far is when the debugger catches an error in
 loaded DLL and opens the right editor tab for it. If I set a breakpoint
 then it also generates breakpoints for functions in the DLL too.
 
 Is there are way to select the loaded DLL when setting a breakpoint I
 don't know?
 


In case you load the DLL dynamically, maybe it helps if you preload the
DLL and it's symbols, e.g. by loading it as a direct dependency of the
executable.
May 08 2021
parent reply frame <frame86 live.com> writes:
On Saturday, 8 May 2021 at 14:26:18 UTC, Rainer Schuetze wrote:


 In case you load the DLL dynamically, maybe it helps if you 
 preload the DLL and it's symbols, e.g. by loading it as a 
 direct dependency of the executable.


I can see in the module window that all symbols are already 
loaded, but still no luck.
It also fails to step-by-step debugging into the exported 
function.

It highly depends in which editor tab the breakpoint is set. If I 
select the wrong one, only the main application gets the 
breakpoint. The main problem is to open this tab in the right 
context in the first place.

It's a arbitrary behavior, for some functions it works better 
than others. Maybe simple functions work better than those which 
are created by static type variants.

Also weird that the debugger even opens the same code tab for 
different stacks but doesn't title it. This seems to be a problem 
with VS too. It would be great if VisualD could provide a 
debugger breakpoint list too which allows to select the module if 
needed because the standard debugger window is not very 
sophisticated anyway.
May 08 2021
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 08/05/2021 21:44, frame wrote:

 On Saturday, 8 May 2021 at 14:26:18 UTC, Rainer Schuetze wrote:
 

 In case you load the DLL dynamically, maybe it helps if you preload
 the DLL and it's symbols, e.g. by loading it as a direct dependency of
 the executable.


 
 I can see in the module window that all symbols are already loaded, but
 still no luck.
 It also fails to step-by-step debugging into the exported function.
 
 It highly depends in which editor tab the breakpoint is set. If I select
 the wrong one, only the main application gets the breakpoint. The main
 problem is to open this tab in the right context in the first place.
 
 It's a arbitrary behavior, for some functions it works better than
 others. Maybe simple functions work better than those which are created
 by static type variants.
 
 Also weird that the debugger even opens the same code tab for different
 stacks but doesn't title it. This seems to be a problem with VS too. It
 would be great if VisualD could provide a debugger breakpoint list too
 which allows to select the module if needed because the standard
 debugger window is not very sophisticated anyway.


Opening the same file twice is probably hinting at the problem: the
source file references in the debug information are different, and VS
thinks they are referring to different files. This probably also affects
break point location resolution.

What compiler are you using? What command line options? Looking at a hex
listing of binary object files might reveal if source file names are
represented differently.
May 09 2021
parent frame <frame86 live.com> writes:
On Sunday, 9 May 2021 at 11:39:27 UTC, Rainer Schuetze wrote:


 Opening the same file twice is probably hinting at the problem: 
 the source file references in the debug information are 
 different, and VS thinks they are referring to different files. 
 This probably also affects break point location resolution.



 What compiler are you using? What command line options? Looking 
 at a hex listing of binary object files might reveal if source 
 file names are represented differently.


Hmm, that may be the problem indeed. I do not compile the DLLs 
via VS (creating/switching different configurations, excluding 
files, etc is so cumbersome). There is no .obj file anymore, only 
.pdb which contains relative paths it seems, however absolute 
path for source files are the same and also compiler arguments 
(dmd).

Well, I need to try to create a clean project structure and 
compile all with VS, maybe that works better.
May 09 2021