Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Register override #8

Open
Cr0a3 opened this issue Aug 23, 2024 · 6 comments
Open

[BUG] Register override #8

Cr0a3 opened this issue Aug 23, 2024 · 6 comments
Assignees
Labels
backend:x64 x64 code generation backend bug Something isn't working

Comments

@Cr0a3
Copy link
Owner

Cr0a3 commented Aug 23, 2024

Describe the bug
Running a simple example from simplelang:

import with (fmt: string, ...) printf // printf from libc

extern with () main: {
    printf("Hello World!\n");

    var x: u32 = 5;

    printf("%d = %d", x, 5);

    return 0;
}

Outputs:

Hello World!
1827627024 = 5

What it shouldn't. Here's the expected output:

Hello World!
5= 5

The 1827627024 is the adress of the formatting string (%d = %d) which means that the register of the variable x gets overrideden.

IR

const .const0 = [ 72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33, 10, ,]
const .const1 = [ 37, 100, 32, 61, 32, 37, 100, ,]
define i32 @main() {
 entry:
    %0 = ptr .const0
    %1 = call i32 printf ptr %0
    %2 = i64 5
    %3 = i64 %2
    %4 = ptr .const1
    %5 = i64 5
    %6 = call i32 printf ptr %4 i64 %3 i64 %5
    %7 = i64 0
    ret i64 %7

}
declare i32 @printf( ptr %0 )

In line: %3 = i64 %2 the compile thinks that %2 is dropped which means it frees the resources. But sussly the resources from the last free aren't assignet back so the register for the variable gets overriden by the next line: %4 = ptr .const1

Generated assembly

// made using ygen v0.1.1
// by Cr0a3

section .rodata

.const0: [72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33, 10, 0] # Hello World!
.const1: [37, 100, 32, 61, 32, 37, 100, 0] # %d = %d
section .text

global main
main:
	push rbp
	mov rbp, rsp
	sub rsp, 40
	lea rax, [ rip+ 1 ]
	 
	mov rcx, rax	# %0 = ptr .const0
	call 0
	 
	mov ecx, eax	# %1 = call i32 printf ptr %0
	mov rcx, 5	# %2 = i64 5	# %3 = i64 %2
	lea rax, [ rip+ 1 ]
	 
	mov rsi, rax	# %4 = ptr .const1
	mov rdi, 5	# %5 = i64 5
	mov rcx, rsi
	mov rdx, rcx
	mov r8, rdi
	call 0
	 
	mov edi, eax	# %6 = call i32 printf ptr %4i64 %3i64 %5
	mov rcx, 0	# %7 = i64 0
	mov rax, rcx	# ret i64 %7
	add rsp, 40
	pop rbp
	ret
global printf
@Cr0a3 Cr0a3 added the bug Something isn't working label Aug 23, 2024
@Cr0a3 Cr0a3 self-assigned this Aug 23, 2024
@Cr0a3 Cr0a3 added the backend Code generation backend label Aug 23, 2024
@Cr0a3 Cr0a3 changed the title [BUG] Register ovverride [BUG] Register override Aug 23, 2024
Cr0a3 added a commit that referenced this issue Aug 23, 2024
@Cr0a3 Cr0a3 closed this as completed Aug 23, 2024
@Cr0a3
Copy link
Owner Author

Cr0a3 commented Aug 23, 2024

Is open for reopen

@Cr0a3
Copy link
Owner Author

Cr0a3 commented Aug 23, 2024

Wasn't fixed i knew it

@Cr0a3 Cr0a3 reopened this Aug 23, 2024
Cr0a3 added a commit that referenced this issue Aug 23, 2024
@Cr0a3
Copy link
Owner Author

Cr0a3 commented Aug 25, 2024

Debugging is a bit hard because gimli-rs/object#721

@Cr0a3 Cr0a3 added backend:x64 x64 code generation backend and removed backend Code generation backend labels Aug 25, 2024
@Cr0a3
Copy link
Owner Author

Cr0a3 commented Aug 25, 2024

Fixed.

After some long debugging sessions i found out why. It's because the variables which are in the registers for the function arguments get overriten and then read for the new argument.
They are also not saved because they aren't used after the call.

Example assembly line:

mov rcx, r10 // r10 = adress of string
mov rdx, rcx // rcx was the variable which is now overriden by the arg
mov r8, rsi
mov r9d, r11d
push rdi
call printf

Yeah, so i need to fix that. Maybe by using the stack?

Cr0a3 added a commit that referenced this issue Aug 27, 2024
Cr0a3 added a commit that referenced this issue Aug 27, 2024
@Cr0a3 Cr0a3 closed this as completed in f27cfe7 Aug 27, 2024
@Cr0a3
Copy link
Owner Author

Cr0a3 commented Aug 27, 2024

Why did github close the issue??

@Cr0a3 Cr0a3 reopened this Aug 27, 2024
@Cr0a3
Copy link
Owner Author

Cr0a3 commented Aug 28, 2024

So i found out the generated assembly code is now correct but the instruction encoding has some errors again!

Cr0a3 pushed a commit that referenced this issue Aug 28, 2024
Cr0a3 added a commit that referenced this issue Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend:x64 x64 code generation backend bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant