dlls
heavenly opened this issue · comments
does this work with dlls that are injected (i'm assuming probably yes because of the ability to attach to running projects, but I'm not sure).
It does not work on code for which there are no symbols in the application PDB. These are used to determine function addresses etc. in the loaded image, so are a hard requirement.
blink does not currently load the PDBs for DLLs loaded by the application (it could do that though).
@crosire Any sort of guidance on how one might start on this? I've started dissecting the code a bit and think I understand the overall flow (though surely not the specifics - not nearly familiar enough with the Windows executable format for that), but I'm not totally sure where to begin in tracking changes to loaded DLL sources, especially those which are loaded at runtime (the use case I'm looking to support).
Thanks in advance!
There are two ways DLLs can be loaded, either via a static import or dynamically via LoadLibrary
.
The first case can be covered by retrieving the PDB info here:
Line 55 in 9ca9e5c
Same way it is done for the main application (get a pointer to the PE header via
GetModuleHandle
and then just locate the PDB path and read the symbol information in the same way): Line 92 in 9ca9e5c
The second case would involve hooking the LoadLibrary
functions and doing the same thing every time a new DLL was loaded.
Has anyone tried to implement patching *.dlls loaded by main executable via static or dynamic import?
Added an untested, experimental branch which loads symbols for statically linked DLLs: https://github.com/crosire/blink/tree/dlls
EDIT: This is now in master.
I have a host.exe app which loads a plugin DLL at runtime. No access to the source code of host.exe app but only have for DLL's. Is that also possible to use blink for this case? If it is, could you let me know how to use blink for that? Thanks in advance.
blink does not currently support dynamically loaded DLLs.