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.

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.

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.

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.