bm icon indicating copy to clipboard operation
bm copied to clipboard

On Windows x86_64 executables can't print values

Open kolumb opened this issue 3 years ago • 1 comments

WriteFile function needs fifth argument that it takes from the stack, according to Microsoft x64 calling convention. Previously it was always null. After changes in #395 it started to take garbage pointer from stack and try to write there. Found that it's fixed if I make this change:

diff --git a/src/library/nasm_sysv_x86_64.c b/src/library/nasm_sysv_x86_64.c
index 6a0cf9d..f2cf21d 100644
--- a/src/library/nasm_sysv_x86_64.c
+++ b/src/library/nasm_sysv_x86_64.c
@@ -266,7 +266,8 @@ stack_push_xmm(output, "xmm1");                         \
                 break;
                 case OS_TARGET_WINDOWS: {
                     // TODO: can we replace `stdout_handler` with a register?
-                    fprintf(output, "    sub rsp, 40\n");
+                    fprintf(output, "    push qword 0\n");
+                    fprintf(output, "    sub rsp, 32\n");
                     fprintf(output, "    mov ecx, STD_OUTPUT_HANDLE\n");
                     fprintf(output, "    call GetStdHandle\n");
                     fprintf(output, "    mov DWORD [stdout_handler], eax\n");

But I not sure if this is a root cause. Also maybe it makes sense to implement testing before fixing.

kolumb avatar Jun 04 '21 02:06 kolumb

ah, I think I know what the cause is; previously we never used the "native stack" (rsp, rbp) for anything, so it was basically always 0-filled.

But #395 also started to push stack frames (for stack traces in debuggers), so now the native stack has stuff on it. I just translated the bm stack stuff to the new convention and didn't really check the windows stuff, sorry.

zhiayang avatar Jun 06 '21 03:06 zhiayang