Breakpoint for EXE to DLL debugging in VisualD (all D)

[Rainer Schuetze]

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.