crosire / blink Goto Github PK

View Code? Open in Web Editor NEW

1.0K 30.0 79.0 185 KB

A tool which allows you to edit source code of any MSVC C++ project live at runtime

License: BSD 2-Clause "Simplified" License

C++ 99.17% CMake 0.83%

c-plus-plus linker pdb live-coding

blink's People

Contributors

Stargazers

Watchers

Forkers

cmaughan foreverdavid linecode whizzter fiona8231 templeblock tithand mohabmohamed cppworks winnerineast daodaoliang nanangarsyad pollend deepankarsharma sapfir63 tralivali1234 sherief niadb mszymczyk bx9566 peterlindgren shadowndacorner ybalrid maxihuesito longjohncoder josephlvulcan kassent jvidziunas iomeone feiyunwill whztt07 ytsedan wbskyboy clusterzx cpp-live-coding phr34k fysu 52bc ioncodes mastermann rasmus-z thelightway wyrover joonvan layptm rikoshet-234 k3v1n1990s killvxk spsforks yang123vc seanmott tsubasa2540 hexlord modulexcite garogers01 lvyitian rocker9527 floatingnumber ahmedsakrr clayne vohi hugmyndakassi 5l1v3r1 aasim-syed mfkiwl bburgin lainswork icyfox168168 oceancx gmh5225 yinchuanming 66hh hanzz2007 cyberflamego postal86 gotanod webstorage119 crackercat

blink's Issues

Question about relocations and static local variables

Hi.
Suppose we have this StaticVar.cpp file:

#include <cstdio>

static int localStaticVar = 10;

void printAndIncrement()
{
    printf("%d", localStaticVar++);
}

We're calling printAndIncrement each frame. We want to reload this file for some reason. We're expecting to get this output:

10
11
12
13
CODE RELOAD
14
15
...

On linux we cannot use relocation data from the StaticVar.cpp.o because such a relocations are 32-bit (probably compiler takes into account the "locality" of localStaticVar relative to printAndIncrement), and in general we cannot insert the address of old localStaticVar into the new version of printAndIncrement. How blink deal with such cases?
Thank you!

File watcher starts for the first file

File watcher should be started for the common root path (d:\devel\pbr in this case), but starts for the first file (d:\devel\pbr\pbr\import\tangent.cpp). Non-existing files added by the linker should be ignored (onecoreuap\windows\directx\misc\dxguid\d3d10guid.cpp)

Reading PE debug info directory ...
  Found program debug database: D:\Devel\pbr\bin\Hot.x64\pbr.pdb
  Found source file: d:\devel\pbr\pbr\import\tangent.cpp
  Found source file: d:\devel\pbr\pbr\import\import_obj.cpp
  Found source file: d:\devel\pbr\pbr\import\import.cpp
  Found source file: d:\devel\pbr\pbr\gui\gui.cpp
  Found source file: d:\devel\pbr\pbr\event\tick.cpp
  Found source file: d:\devel\pbr\pbr\event\input_win.cpp
  Found source file: d:\devel\pbr\pbr\event\input.cpp
  Found source file: d:\devel\pbr\pbr\dx11\states11.cpp
  Found source file: d:\devel\pbr\pbr\dx11\render11.cpp
  Found source file: d:\devel\pbr\pbr\dx11\import11.cpp
  Found source file: d:\devel\pbr\pbr\dx11\device11.cpp
  Found source file: d:\devel\pbr\pbr\base\transform.cpp
  Found source file: d:\devel\pbr\pbr\base\log.cpp
  Found source file: d:\devel\pbr\pbr\base\hresult.cpp
  Found source file: d:\devel\pbr\pbr\base\file.cpp
  Found source file: d:\devel\pbr\pbr\base\allocator.cpp
  Found source file: d:\devel\pbr\pbr\app\main.cpp
  Found source file: d:\devel\pbr\imgui\imgui_widgets.cpp
  Found source file: d:\devel\pbr\imgui\imgui_draw.cpp
  Found source file: d:\devel\pbr\imgui\imgui_demo.cpp
  Found source file: d:\devel\pbr\imgui\imgui.cpp
  Found source file: onecoreuap\windows\directx\misc\dxguid\d3d10guid.cpp
Starting compiler process ...
  Started process with PID 7756
Starting file system watcher for 'd:\devel\pbr\pbr\import\tangent.cpp'

blink.exe crash when editing program built with the /bigobj flag

I just found out about this project and it looks really interesting. 😃

I'm trying to see if I can edit code from a little game engine project I have and see the result right away with blink.

The target program is built in Debug mode.

I attach blink.exe to the program by giving it the PID.

When I modify a file, I have a debug assertion triggered inside vector's operator().

This occurs in blink::application::build_compile_command_line() when creating
std::vector<char> debug_data(section->SizeOfRawData);

section here is an iterator returned by the std::find_if function that seems to look for a section of the name .debug$S but doesn't find it.

The value of the iterator is never checked before de-referencing it.

I'm currently trying to understand why my program doesn't have a "debug" section here, but I really feel like the following code should only be executed after testing section != sections.end() to check if it was found... 🤔

Troubleshooting target program crash

Hey, thanks for this great library! I am having trouble making it work though.
Here is what I tried:

get the blink repo
build blink x64 Debug (Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27012.6 for x64)
create target directory & cd there
create test.cpp with:

#include <iostream>
void fn();
int main() {
	while (true) {
		fn();
	}
}

using std::cout; using std::endl;
void fn() {
	cout << "Hello World" << endl;
}

compile test.cpp in a VS console with cl.exe /Z7 /Od /MDd /nologo /EHsc /std:c++latest test.cpp
cd back to blink root
launch blink with test.exe (bin\x64\Debug\blink.exe target\test.exe) in VS console
output:
Launching in target application ...
Entry point was written to address 000000013F1A0000
Reading PE import directory ...
Reading PE debug info directory ...
Found program debug database: C:\dev\blink\target\test.pdb
Found source file: c:\dev\blink\target\test.cpp
Starting compiler process ...
Started process with PID 31796
Starting file system watcher for 'c:\dev\blink\target' ...
change output string in test.cpp to something else & save
output:
Detected modification to: c:\dev\blink\target\test.cpp
Finished compiling "c:\dev\blink\target\test.obj" with code 0.
Successfully linked object file into executable image.
Detected modification to: c:\dev\blink\target\test.cpp
The target application has exited with code 3221225501.
the test.exe program crashes
the additional change in blink was that I disabled commandline detection from the .obj file, as that didn't work, so the commandline used to build is the built-in (as described in #13)

File changes not detected

Built blink and test exe in VS2017 x86 env. Compiled with /ZI.

Executed the below:
blink.exe test.exe

When i change the source in test app, blink doesn't detect the changes. Sometimes target application crashed with 0x80000003 error.

When i debug blink, ReadFile() function returns size 0 and its came out from while in next iteration.

Include path

Hello!

I managed to get the example project in #30 running, after having fought with #31, but then ran into one more issue with the include path not seeming to be taken into account by blink.

Original Program

From #30.

#include <iostream>
#include <windows.h>

void changefunction() {
    static int n = 6;
    // n = 0;
    std::cout << n++ << std::endl;
}


int main(int argc, char** argv) {

    while (true)
    {
        changefunction();
        Sleep(1000);
    }

    return 0;

This builds fine, and changing anything in changefunction works well. But now look here.

Changed program

#include <iostream>
#include <windows.h>
#include "cannot_be_found.h"

void changefunction() {
...

The problem

There are two of them; one making the other harder to spot.

blink does not report the error
The error being that "cannot_be_found.h".. cannot be found

The error message is sporadic however, I suspect some issue with STDOUT and buffering. Here's what I typically see.

Detected modification to: C:\Users\marcus\source\repos\ConsoleApplication1\ConsoleApplication1.cpp
ConsoleApplication1.cpp

Finished compiling "C:\Users\marcus\source\repos\ConsoleApplication1\ConsoleApplication1.temp.obj" with code 2.

That empty space there appears related to whether or not there's an error. When compilation succeeds, the empty line is replaced with..

Successfully linked object file into executable image.

The workaround

I found that if I replicate my include path in the environment where blink is called, things appear to work.

$ set INCLUDE=all;the;things;VS;included
$ blink.exe consoleapplication1.exe
win!

Is there another way to cope with this? I couldn't find mention of this anywhere, but I don't see how blink could be used without it?

support CMake

Hello, maybe instead of sln, you should support CMake so that you can build for different studios?

I can create pull request

Thanks

not compatible with PCH

because it removes /ZI? At least cl was called without any /Z* debug option

error C2855: commandline option '/Z7' inconsistent with precompiled header

Function to sync patching time

First if all, I like this project a lot. I have been testing for two weeks against live++, and I like your approach when no changes are made to the program, it is very convenient, but there are moments when patching seems occurs at the moment of program execution and the program crashes.

Maybe you could add some agreement concerning the name of a certain global static function (___sync or something like that) which you can hook and make patching only when there is a call to this function.
if such a function is not found in the program, then run patching at any time as original behavior

And I would also like to have a global callback that would be called upon successful patching, but in any case, it can be combined with the sync function if it can return a bool.

Thank you!

Support for exceptions

Hi @crosire,

This isn't a bug report, I just wanted to document that exceptions don't appear to be supported by blink (?)

I'm initially had issues with VS2019 but luckily found #30 which got me half-way there, except the default "Console Application" preset in VS comes with exceptions enabled, which prompts the following error.

Unresolved external symbol '?uncaught_exception@std@@YA_NXZ'.

Full output

$ blink.exe ConsoleApplication1.exe
Launching in target application ...
  Entry point was written to address 000001B91B9D0000
Reading PE import directory ...
Reading PE debug info directory ...
  Found program debug database: C:\Users\marcus\source\repos\ConsoleApplication1\x64\Debug\ConsoleApplication1.pdb
  Found source file: C:\Users\marcus\source\repos\ConsoleApplication1\ConsoleApplication1.cpp
Starting compiler process ...
  Started process with PID 14996
Starting file system watcher for 'C:\Users\marcus\source\repos\ConsoleApplication1' ...
Detected modification to: C:\Users\marcus\source\repos\ConsoleApplication1\ConsoleApplication1.cpp
ConsoleApplication1.cpp
Finished compiling "C:\Users\marcus\source\repos\ConsoleApplication1\ConsoleApplication1.temp.obj" with code 0.
Unresolved external symbol '?uncaught_exception@std@@YA_NXZ'.
The target application has exited with code 3221225786.
^C

Initially I suspected that maybe blink needs to be built with exceptions in order to support it, but it already was. Turning off C++ exceptions for the console application solved it.

Dependent libraries and static storage duration data

Blink is amazing, but I can see a couple issues right now:

Linked libraries. Many projects are designed in a modular way: executable and a bunch of libraries linked to it. Currently blink works only with compilation units linked directly to the executable;
Static storage duration data. After the first hot reload addresses of static variables are changed, and these variables seem contain zero-initialized data. Would be nice if these variables keep the old addresses. Currently I have no idea how to resolve this issue;
Sometimes blink and executable, blink is connected to, hang with the following message in terminal:
Finished compiling "c:\my_project\source\foo.obj" with code 0.
I'm trying to find the cause, but no success yet.

I'm working on these when I have some free time, so if you have any ideas, please, let me know.

File watcher should watch subdirectories

File watcher only scans for changes in the root directory, subdirectories should also be watched.

Linker issues

Hi, I'm aware that blink isn't supposed to work when changing the data layout of structs/classes but I have a question related to linking:

If a program has been compiled and linked with a struct such as

struct test
{
    int i;
};

and then blink is used to change it to

struct test
{
    int i;
    float f;
};

Then blink may not find some symbols such as:
Unresolved external symbol '_fltused'
or if we try to std::cout the new float member:
Unresolved external symbol '__imp_??6?$basic_ostream@DU?$char_traits@D@std@@@std@@QEAAAEAV01@M@Z'

My question is why can't blink find these symbols in the object file? Are these symbols only emitted at linking time?

And how can blink be changed to fix this kind of issue?

Thanks.

'cl.exe' is not recognized as an internal or external command

Hi I'm sure I set /ZI (not /Zi) compile flag but I get cl.exe error with vs 2019.

compiler error messages not displayed

When #20 occurred I didn't get any error messages, even when commenting out the "Only print error information" if @ blink.cpp:283

Maybe it should keep stderr separate from stdout and always print it instead of merging and parsing?
That might also fix another usability issue: if you compile without /ZI and blink is run from a normal cmd (not VS dev) it can't find cl.exe but no error message is displayed ("cl.exe is not recognized...")

DWARF and other platforms?

Hi. Thank you very much for your work! Any chance to see the port of blink to use on another platforms? I'm not experienced in it, but I guess DWARF should have enough data for doing that. Are you aware of this?

Does this work with Visual Studio 2022?

Hi,

I briefly tried firing this up with Visual Studio 2022, the project built fine after doing the auto upgrade and I can run it but haven't been able to get any file changes picked up by the file watcher. So I wanted to check - is this project compatible with VS 2022 / v143 toolset, or is 2017's toolset still required?

Thanks,
Rich

header file changes

How does it handle header file changes?
I guess it's not possible figure out which source files are affected.

comparison with "edit and continue"

How does it compare to /ZI?
Implementation details, performance, limitations.
Would be good to add that to the readme.

How to get it to work?

Thanks for your great work first!
I try blink with the "example_glfw_opengl3" project from ImGui examples. But it can't work.

All code and project of blink and imgui examples are clone from github repo just now and I didn't change anything. I use VS2017 with Windows SDK Version 10.0.17763.0 on Windows10. I did the following steps:

s1 Build example_glfw_opengl3 Debug|Win32.
s2 Build blink Debug|x86 and copy blink.exe into "imgui\examples\example_glfw_opengl3\Debug" directory.
s3 Open windows's cmd console and enter "imgui\examples\example_glfw_opengl3\Debug" where the example_glfw_opengl3.exe is in.
s4 Invoke "blink example_glfw_opengl3.exe" in the console. example_glfw_opengl3.exe got to run.

D:\lab\imgui\examples\example_glfw_opengl3\Debug>blink example_glfw_opengl3.exe Launching in target application ... Entry point was written to address 07B30000 Reading PE import directory ... Reading PE debug info directory ... Found program debug database: D:\lab\imgui\examples\example_glfw_opengl3\Debug\example_glfw_opengl3.pdb Found source file: d:\lab\imgui\examples\example_glfw_opengl3\main.cpp Found source file: d:\lab\imgui\examples\imgui_impl_opengl3.cpp Found source file: d:\lab\imgui\examples\imgui_impl_glfw.cpp Found source file: d:\lab\imgui\imgui_widgets.cpp Found source file: d:\lab\imgui\imgui_draw.cpp Found source file: d:\lab\imgui\imgui_demo.cpp Found source file: d:\lab\imgui\imgui.cpp Starting compiler process ... Started process with PID 137948 Starting file system watcher for 'd:\lab\imgui' ...

Yes, as you see, everything seems to be right.

s5 When I modify some code in main.cpp of example_glfw_opengl3, such as I modify "ImGui::Begin("Hello, world!");" to be "ImGui::Begin("Hello, blink!");", I get the console log info in console:

Detected modification to: d:\lab\imgui\examples\example_glfw_opengl3\main.cpp Finished compiling "d:\lab\imgui\examples\example_glfw_opengl3\main.obj" with code 0. Successfully linked object file into executable image.

Everything seems to be right too. But the result could be seen in ImGUI rendering window.
I also try run blink in VS debug mode and set the working directory and Command Arguments to point to imgui_impl_opengl3.

Failed to start file system watcher

Hello!

I have tried to run blink on a couple projects, but every time I get the same error:

Launching in target application ...
  Entry point was written to address 0123456789ABCDEF
Reading PE import directory ...
Reading PE debug info directory ...
  Found program debug database: C:\my_project\_build\my_project.pdb
  Found source file: c:\my_project\foo.cpp
  Found source file: c:\my_project\bar.cpp
  Found source file: c:\my_project\main.cpp
Starting compiler process ...
  Started process with PID 123
Starting file system watcher for '' ...
  Error: Could not open directory handle.
The target application has exited with code 259.

I debugged blink for a couple minutes and found out that in method blink::pdb_reader::read_link_info variable stream has size of 0. The item pdb_reader::_named_streams["/LinkInfo"] exists and is equal to 5. msf_reader::_streams[5].page_indices is an empty vector.

Is there some compilation/linkage flag I'm missing?

I'm using MSVC 2017, version 15.7.5.

won't work for a simple test.

environment:

visual studio 2019
std:c++latest

code:

#include <iostream>
#include <windows.h>

void changefunction()
{
    static int n = 0;
    std::cout << n++ << std::endl;
    //std::cout << "add msg" << std::endl;
}
int main(int argc,char** argv)
{

    while (true)
    {
        changefunction();
        Sleep(1000);
    }

    return 0;
}

test step:

blink.exe "C:\Users\kk\source\repos\ConsoleApplication1\x64\Debug\ConsoleApplication1.exe"
uncomment " //std::cout << "add msg" << std::endl;"
save file
output:

Launching in target application ...
  Entry point was written to address 0000024D24CE0000
Reading PE import directory ...
Reading PE debug info directory ...
  Found program debug database: C:\Users\kk\source\repos\ConsoleApplication1\x64\Debug\ConsoleApplication1.pdb
  Found source file: C:\Users\kk\source\repos\ConsoleApplication1\ConsoleApplication1.cpp
Starting compiler process ...
  Started process with PID 10532
Starting file system watcher for 'C:\Users\kk\source\repos\ConsoleApplication1' ...
Detected modification to: C:\Users\kk\source\repos\ConsoleApplication1\ConsoleApplication1.cpp
ConsoleApplication1.cpp

Finished compiling "C:\Users\kk\source\repos\ConsoleApplication1\ConsoleApplication1.temp.obj" with code 2.

program output:

nothing changed here, is there any steps wrong?

cl.exe not found

Hi,

I've built a simple hello world application with /Zi and VS 17 community edition version 15.8.7 with an x64 build of the 19.00.24234.1 compiler.

I got an error saying it couldn't find cl.exe. Hard coding cl.exe to the correct path then gives the error: Cannot open include file 'windows.h'. I'd rather not have to mess around with vcvarsall.bat...

Any ideas why this seems to work for other people but not on my machine? Thanks.

help

is there any special setup required? I'm not able to get it to reload, although the command line outputs:

Detected modification to: E:\imgui\examples\example_win32_directx11\main.cpp
Finished compiling "E:\imgui\examples\example_win32_directx11\main.obj" with code 0.
Successfully linked object file into executable image.

my setup:

Windows 10
VS2017
target app: DearImGUI examples.

dlls

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).

Duplicate file modification notifications

Adding this issue here for tracking: Depending on which editor is used to edit a source code file, upon saving the file is often modified multiple times so that the ReadDirectoryChangedW API will report multiple notifications for the same file. This causes blink to compile the file multiple times, which is unoptimal and slows it down. blink should try and detect when a file notification is a duplicate and ignore those.

Use compilation command stored in obj file

I believe full compilation command is stored in on of .debug$S sections of obj file.

dumpbin /section:.debug$S /rawdata main.obj

Excerpt from the dump:

SECTION HEADER #2
.debug$S name
       0 physical address
       0 virtual address
   31FC8 size of raw data
   18CFB file pointer to raw data (00018CFB to 0004ACC2)
   4ACC3 file pointer to relocation table
       0 file pointer to line numbers
      A6 number of relocations
       0 number of line numbers
42100040 flags
         Initialized Data
         Discardable
         1 byte align
         Read Only

RAW DATA #2
  00000000: 04 00 00 00 F1 00 00 00 FC 06 00 00 2E 00 01 11  ....n...ü.......
  00000010: 00 00 00 00 44 3A 5C 44 65 76 65 6C 5C 70 62 72  ....D:\Devel\pbr
  00000020: 5C 62 75 69 6C 64 5C 48 6F 74 2E 78 36 34 5C 70  \build\Hot.x64\p
  00000030: 62 72 5C 6D 61 69 6E 2E 6F 62 6A 00 3A 00 3C 11  br\main.obj.:.<.
  00000040: 01 41 00 00 D0 00 13 00 0F 00 69 68 00 00 13 00  .A..?.....ih....
  00000050: 0F 00 69 68 00 00 4D 69 63 72 6F 73 6F 66 74 20  ..ih..Microsoft 
  00000060: 28 52 29 20 4F 70 74 69 6D 69 7A 69 6E 67 20 43  (R) Optimizing C
  00000070: 6F 6D 70 69 6C 65 72 00 B1 05 3D 11 01 63 77 64  ompiler.±.=..cwd
  00000080: 00 44 3A 5C 44 65 76 65 6C 5C 70 62 72 5C 70 62  .D:\Devel\pbr\pb
  00000090: 72 00 63 6C 00 43 3A 5C 50 72 6F 67 72 61 6D 20  r.cl.C:\Program 
  000000A0: 46 69 6C 65 73 20 28 78 38 36 29 5C 4D 69 63 72  Files (x86)\Micr
  000000B0: 6F 73 6F 66 74 20 56 69 73 75 61 6C 20 53 74 75  osoft Visual Stu
  000000C0: 64 69 6F 5C 32 30 31 37 5C 43 6F 6D 6D 75 6E 69  dio\2017\Communi
  000000D0: 74 79 5C 56 43 5C 54 6F 6F 6C 73 5C 4D 53 56 43  ty\VC\Tools\MSVC
  000000E0: 5C 31 34 2E 31 35 2E 32 36 37 32 36 5C 62 69 6E  \14.15.26726\bin
  000000F0: 5C 48 6F 73 74 58 38 36 5C 78 36 34 5C 43 4C 2E  \HostX86\x64\CL.
  00000100: 65 78 65 00 63 6D 64 00 2D 63 20 2D 49 44 3A 5C  exe.cmd.-c -ID:\
  00000110: 44 65 76 65 6C 5C 70 62 72 5C 70 62 72 20 2D 49  Devel\pbr\pbr -I
  00000120: 44 3A 5C 44 65 76 65 6C 5C 70 62 72 5C 62 75 69  D:\Devel\pbr\bui
  00000130: 6C 64 5C 48 6F 74 2E 78 36 34 5C 70 62 72 5C 73  ld\Hot.x64\pbr\s
  00000140: 68 61 64 65 72 73 20 2D 49 44 3A 5C 44 65 76 65  haders -ID:\Deve
  00000150: 6C 5C 70 62 72 5C 69 6D 67 75 69 20 2D 49 44 3A  l\pbr\imgui -ID:
  00000160: 5C 44 65 76 65 6C 5C 70 62 72 5C 76 69 73 69 74  \Devel\pbr\visit
  00000170: 5F 73 74 72 75 63 74 5C 69 6E 63 6C 75 64 65 20  _struct\include 
  00000180: 2D 5A 49 20 2D 4A 4D 43 20 2D 6E 6F 6C 6F 67 6F  -ZI -JMC -nologo
  00000190: 20 2D 57 33 20 2D 57 58 2D 20 2D 64 69 61 67 6E   -W3 -WX- -diagn
  000001A0: 6F 73 74 69 63 73 3A 63 6C 61 73 73 69 63 20 2D  ostics:classic -
  000001B0: 73 64 6C 2D 20 2D 4D 50 20 2D 4F 64 20 2D 44 5F  sdl- -MP -Od -D_
  000001C0: 44 45 42 55 47 20 2D 44 5F 57 49 4E 44 4F 57 53  DEBUG -D_WINDOWS
  000001D0: 20 2D 44 5F 57 49 4E 33 32 5F 57 49 4E 4E 54 3D   -D_WIN32_WINNT=
  000001E0: 30 78 30 36 30 30 20 2D 44 57 49 4E 33 32 20 2D  0x0600 -DWIN32 -
  000001F0: 44 5F 55 4E 49 43 4F 44 45 20 2D 44 55 4E 49 43  D_UNICODE -DUNIC
  00000200: 4F 44 45 20 2D 47 46 20 2D 47 6D 2D 20 2D 45 48  ODE -GF -Gm- -EH
  00000210: 73 20 2D 45 48 63 20 2D 52 54 43 31 20 2D 4D 44  s -EHc -RTC1 -MD
  00000220: 64 20 2D 47 53 2D 20 2D 66 70 3A 70 72 65 63 69  d -GS- -fp:preci
  00000230: 73 65 20 2D 70 65 72 6D 69 73 73 69 76 65 2D 20  se -permissive- 
  00000240: 2D 5A 63 3A 77 63 68 61 72 5F 74 20 2D 5A 63 3A  -Zc:wchar_t -Zc:
  00000250: 66 6F 72 53 63 6F 70 65 20 2D 5A 63 3A 69 6E 6C  forScope -Zc:inl
  00000260: 69 6E 65 20 2D 73 74 64 3A 63 2B 2B 31 37 20 2D  ine -std:c++17 -
  00000270: 46 6F 44 3A 5C 44 65 76 65 6C 5C 70 62 72 5C 62  FoD:\Devel\pbr\b
  00000280: 75 69 6C 64 5C 48 6F 74 2E 78 36 34 5C 70 62 72  uild\Hot.x64\pbr
  00000290: 5C 20 2D 46 64 44 3A 5C 44 65 76 65 6C 5C 70 62  \ -FdD:\Devel\pb
  000002A0: 72 5C 62 75 69 6C 64 5C 48 6F 74 2E 78 36 34 5C  r\build\Hot.x64\
  000002B0: 70 62 72 5C 76 63 31 34 31 2E 70 64 62 20 2D 47  pbr\vc141.pdb -G
  000002C0: 64 20 2D 54 50 20 2D 46 43 20 2D 65 72 72 6F 72  d -TP -FC -error
  000002D0: 72 65 70 6F 72 74 3A 70 72 6F 6D 70 74 20 2D 49  report:prompt -I
  000002E0: 22 43 3A 5C 50 72 6F 67 72 61 6D 20 46 69 6C 65  "C:\Program File
  000002F0: 73 20 28 78 38 36 29 5C 4D 69 63 72 6F 73 6F 66  s (x86)\Microsof
  00000300: 74 20 56 69 73 75 61 6C 20 53 74 75 64 69 6F 5C  t Visual Studio\
  00000310: 32 30 31 37 5C 43 6F 6D 6D 75 6E 69 74 79 5C 56  2017\Community\V
  00000320: 43 5C 54 6F 6F 6C 73 5C 4D 53 56 43 5C 31 34 2E  C\Tools\MSVC\14.
  00000330: 31 35 2E 32 36 37 32 36 5C 69 6E 63 6C 75 64 65  15.26726\include
  00000340: 22 20 2D 49 22 43 3A 5C 50 72 6F 67 72 61 6D 20  " -I"C:\Program 
  00000350: 46 69 6C 65 73 20 28 78 38 36 29 5C 4D 69 63 72  Files (x86)\Micr
  00000360: 6F 73 6F 66 74 20 56 69 73 75 61 6C 20 53 74 75  osoft Visual Stu
  00000370: 64 69 6F 5C 32 30 31 37 5C 43 6F 6D 6D 75 6E 69  dio\2017\Communi
  00000380: 74 79 5C 56 43 5C 54 6F 6F 6C 73 5C 4D 53 56 43  ty\VC\Tools\MSVC
  00000390: 5C 31 34 2E 31 35 2E 32 36 37 32 36 5C 61 74 6C  \14.15.26726\atl
  000003A0: 6D 66 63 5C 69 6E 63 6C 75 64 65 22 20 2D 49 22  mfc\include" -I"
  000003B0: 43 3A 5C 50 72 6F 67 72 61 6D 20 46 69 6C 65 73  C:\Program Files
  000003C0: 20 28 78 38 36 29 5C 4D 69 63 72 6F 73 6F 66 74   (x86)\Microsoft
  000003D0: 20 56 69 73 75 61 6C 20 53 74 75 64 69 6F 5C 32   Visual Studio\2
  000003E0: 30 31 37 5C 43 6F 6D 6D 75 6E 69 74 79 5C 56 43  017\Community\VC
  000003F0: 5C 41 75 78 69 6C 69 61 72 79 5C 56 53 5C 69 6E  \Auxiliary\VS\in
  00000400: 63 6C 75 64 65 22 20 2D 49 22 43 3A 5C 50 72 6F  clude" -I"C:\Pro
  00000410: 67 72 61 6D 20 46 69 6C 65 73 20 28 78 38 36 29  gram Files (x86)
  00000420: 5C 57 69 6E 64 6F 77 73 20 4B 69 74 73 5C 31 30  \Windows Kits\10
  00000430: 5C 49 6E 63 6C 75 64 65 5C 31 30 2E 30 2E 31 37  \Include\10.0.17
  00000440: 37 36 33 2E 30 5C 75 63 72 74 22 20 2D 49 22 43  763.0\ucrt" -I"C
  00000450: 3A 5C 50 72 6F 67 72 61 6D 20 46 69 6C 65 73 20  :\Program Files 
  00000460: 28 78 38 36 29 5C 57 69 6E 64 6F 77 73 20 4B 69  (x86)\Windows Ki
  00000470: 74 73 5C 31 30 5C 49 6E 63 6C 75 64 65 5C 31 30  ts\10\Include\10
  00000480: 2E 30 2E 31 37 37 36 33 2E 30 5C 75 6D 22 20 2D  .0.17763.0\um" -
  00000490: 49 22 43 3A 5C 50 72 6F 67 72 61 6D 20 46 69 6C  I"C:\Program Fil
  000004A0: 65 73 20 28 78 38 36 29 5C 57 69 6E 64 6F 77 73  es (x86)\Windows
  000004B0: 20 4B 69 74 73 5C 31 30 5C 49 6E 63 6C 75 64 65   Kits\10\Include
  000004C0: 5C 31 30 2E 30 2E 31 37 37 36 33 2E 30 5C 73 68  \10.0.17763.0\sh
  000004D0: 61 72 65 64 22 20 2D 49 22 43 3A 5C 50 72 6F 67  ared" -I"C:\Prog
  000004E0: 72 61 6D 20 46 69 6C 65 73 20 28 78 38 36 29 5C  ram Files (x86)\
  000004F0: 57 69 6E 64 6F 77 73 20 4B 69 74 73 5C 31 30 5C  Windows Kits\10\
  00000500: 49 6E 63 6C 75 64 65 5C 31 30 2E 30 2E 31 37 37  Include\10.0.177
  00000510: 36 33 2E 30 5C 77 69 6E 72 74 22 20 2D 49 22 43  63.0\winrt" -I"C
  00000520: 3A 5C 50 72 6F 67 72 61 6D 20 46 69 6C 65 73 20  :\Program Files 
  00000530: 28 78 38 36 29 5C 57 69 6E 64 6F 77 73 20 4B 69  (x86)\Windows Ki
  00000540: 74 73 5C 31 30 5C 49 6E 63 6C 75 64 65 5C 31 30  ts\10\Include\10
  00000550: 2E 30 2E 31 37 37 36 33 2E 30 5C 63 70 70 77 69  .0.17763.0\cppwi
  00000560: 6E 72 74 22 20 2D 49 22 43 3A 5C 50 72 6F 67 72  nrt" -I"C:\Progr
  00000570: 61 6D 20 46 69 6C 65 73 20 28 78 38 36 29 5C 57  am Files (x86)\W
  00000580: 69 6E 64 6F 77 73 20 4B 69 74 73 5C 4E 45 54 46  indows Kits\NETF
  00000590: 58 53 44 4B 5C 34 2E 36 2E 31 5C 49 6E 63 6C 75  XSDK\4.6.1\Inclu
  000005A0: 64 65 5C 75 6D 22 20 2D 49 22 43 3A 5C 50 72 6F  de\um" -I"C:\Pro
  000005B0: 67 72 61 6D 20 46 69 6C 65 73 20 28 78 38 36 29  gram Files (x86)
  000005C0: 5C 57 69 6E 64 6F 77 73 20 4B 69 74 73 5C 4E 45  \Windows Kits\NE
  000005D0: 54 46 58 53 44 4B 5C 34 2E 36 2E 31 5C 49 6E 63  TFXSDK\4.6.1\Inc
  000005E0: 6C 75 64 65 5C 75 6D 22 20 2D 58 00 73 72 63 00  lude\um" -X.src.
  000005F0: 61 70 70 5C 6D 61 69 6E 2E 63 70 70 00 70 64 62  app\main.cpp.pdb
  00000600: 00 44 3A 5C 44 65 76 65 6C 5C 70 62 72 5C 62 75  .D:\Devel\pbr\bu
  00000610: 69 6C 64 5C 48 6F 74 2E 78 36 34 5C 70 62 72 5C  ild\Hot.x64\pbr\
  00000620: 76 63 31 34 31 2E 70 64 62 00 00 09 00 24 11 6C  vc141.pdb....$.l
  00000630: 6F 67 67 65 72 00 09 00 24 11 69 6D 70 6F 72 74  ogger...$.import
  00000640: 00 0C 00 24 11 4D 69 63 72 6F 73 6F 66 74 00 06  ...$.Microsoft..
  00000650: 00 24 11 57 52 4C 00 0A 00 24 11 44 65 74 61 69  .$.WRL...$.Detai
...

This command could be used to recompile modified source files. Right now compilation command has to be hardcoded in the blink.exe.

Ideas to make it language agnostic

Hello,

Since it works on the obj level, i was wondering what it would take to make it language agnostic

What do you think would be needed to achieve it?

Zig: I tried on a zig program, it finds .c source file used, i tried with nuklear library, unfortunatly it fails at recompilation

C:\dev\kdomz\zig-cache\o\05423ee6f5c0857d2386fe7c8a148e2e>blink.exe game.exe
Launching in target application ...
  Entry point was written to address 00007FF7DBAA0000
Reading PE import directory ...
Reading PE debug info directory ...
  Found program debug database: C:\dev\kdomz\zig-cache\o\05423ee6f5c0857d2386fe7c8a148e2e\game.pdb
  Found source file: C:\dev\kdomz\projects\c\nuklear\nuklear.c
  Found source file: C:\dev\kdomz\projects\c\glad\glad.c
  Found source file: C:\dev\kdomz\projects\c\mongoose\mongoose.c
Starting compiler process ...
  Started process with PID 2424
Starting file system watcher for 'C:\dev\kdomz\projects\c' ...
Starting file system watcher for 'C:\dev\kdomz\projects\c' ...
Starting file system watcher for 'C:\dev\kdomz\projects\c\mongoose' ...
Detected modification to: C:\dev\kdomz\projects\c\nuklear\nuklear.c
nuklear.c
Finished compiling "C:\dev\kdomz\projects\c\nuklear\nuklear.temp.obj" with code 0.
Unresolved external symbol 'fabs'.

D: I also tried on a D program, no C code used so it didn't work:

./blink.exe game.exe
Launching in target application ...
  Entry point was written to address 00007FF769740000
Reading PE import directory ...
Reading PE debug info directory ...
  Found program debug database: C:\dev\kdom\bin\game.pdb
  Error: Could not determine source directories. Check your program debug database for source files.
The target application has exited with code 259.

Is a C source important? or is my assumption that it only need the object file correct?

If only the object file correct, could there be an option added to watch a specific file name

i compile game to game.exe game.obj game.pdb
i start the game ./blink.exe game.exe and make it watch game-reload.obj
i compile the game to game-reload.exe game-reload.obj game-reload.pdb
blink check the new object file and patches the original game.obj

Would that work?

Thanks!

Crash on PE import from WS2_32.dll

Target process crashes with access violation during initial remote thread injection:

 	blink.exe!std::char_traits<char>::length(const char * const _First) Line 462	C++
 	blink.exe!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign(const char * const _Ptr) Line 2676	C++
 	blink.exe!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> >(const char * const _Ptr) Line 2185	C++
 	blink.exe!std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,void *>::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,void *><char const (&)[1],void *,0>(const char[1] & _Val1, void * && _Val2) Line 173	C++
>	blink.exe!blink::application::run() Line 74	C++
 	blink.exe!remote_main(unsigned char * imagebase) Line 101	C++

I debugged target process. Symbols from dxgi.dll and d3d11 are properly initialized, but process fails on access to import->Name from WS2_32.dll, content of import_name_table[k].u1.AddressOfData looks very suspicious (0x800000000000006f). Addresses from other libraries are OK.

Output from debugger:

_symbols
{ size=0x0000000000000003 }
    [hash_function]: hash
    [key_eq]: equal_to
    [allocator]: allocator
    ["__ImageBase"]: ("__ImageBase", pbr.exe!0x00007ff65e6a0000)
    ["CreateDXGIFactory1"]: ("CreateDXGIFactory1", 0x00007ffa0210a200 {dxgi.dll!CreateDXGIFactory1(void)})
    ["D3D11CreateDevice"]: ("D3D11CreateDevice", 0x00007ffa001d5800 {d3d11.dll!D3D11CreateDevice(void)})
    [Raw View]: {...}

(const char *)(_image_base + import_directory_entries[0].Name)
0x00007ff65e84a104 "d3d11.dll"

(const IMAGE_THUNK_DATA *)(_image_base + import_directory_entries[0].Characteristics)
pbr.exe!0x00007ff65e849dd8 {u1={ForwarderString=0x00000000001aa0f0 Function=0x00000000001aa0f0 Ordinal=...} }
    u1: {ForwarderString=0x00000000001aa0f0 Function=0x00000000001aa0f0 Ordinal=0x00000000001aa0f0 ...}

(const char *)(_image_base + import_directory_entries[1].Name)
0x00007ff65e84a124 "dxgi.dll"

(const IMAGE_THUNK_DATA *)(_image_base + import_directory_entries[1].Characteristics)
pbr.exe!0x00007ff65e849de8 {u1={ForwarderString=0x00000000001aa10e Function=0x00000000001aa10e Ordinal=...} }
    u1: {ForwarderString=0x00000000001aa10e Function=0x00000000001aa10e Ordinal=0x00000000001aa10e ...}

(const char *)(_image_base + import_directory_entries[2].Name)
0x00007ff65e84a14c "WS2_32.dll"

(const IMAGE_THUNK_DATA *)(_image_base + import_directory_entries[2].Characteristics)
pbr.exe!0x00007ff65e849d90 {u1={ForwarderString=0x800000000000006f Function=0x800000000000006f Ordinal=...} }
    u1: {ForwarderString=0x800000000000006f Function=0x800000000000006f Ordinal=0x800000000000006f ...}

(const char *)(_image_base + import_directory_entries[3].Name)
0x00007ff65e84a35e "KERNEL32.dll"

(const IMAGE_THUNK_DATA *)(_image_base + import_directory_entries[4].Characteristics)
pbr.exe!0x00007ff65e849b88 {u1={ForwarderString=0x00000000001aa65e Function=0x00000000001aa65e Ordinal=...} }
    u1: {ForwarderString=0x00000000001aa65e Function=0x00000000001aa65e Ordinal=0x00000000001aa65e ...}

...

I "fixed" the problem by ignoring symbol addresses with highest bit set:

// Ignore symbol if MSB set in RVA, todo 32bit, ordinal lookup?
if ((import_name_table[k].u1.AddressOfData & 0x8000000000000000) == 0)
{
	const auto import = reinterpret_cast<const IMAGE_IMPORT_BY_NAME *>(_image_base + import_name_table[k].u1.AddressOfData);
	_symbols.insert({ import->Name, reinterpret_cast<void *>(import_address_table[k].u1.AddressOfData) });
}

I tried to dig through PE spec but didn't find anything useful. Maybe this is a lookup by ordinal number? Any ideas?

Win10 x64 Pro v1803 (17134.471), Windows SDK 10.0.17763.0