~rosiepie

https://github.com/acquitelol

16 yrs old - she/her

tldr: i work in rust and ts, i love mv-calculus, react, reverse-engineering and algorithms

experienced heaviest in rust and typescript but i can also work in objective c, c#, python, etc

i've messed a lot with the react internals and i understand how the rendering process works to a good extent. i've worked on tools which require hoisting react to hook its methods and as such i understand how the tree works, how hooks work internally, how to optimize the code, how the react dispatcher and virtual dom works, how react-dom renders the react tree, etc.

my main source of knowledge is reverse engineering- specifically discord react native client modifications

i also have an ongoing project for my own c-style language called Elle that i wrote in Rust which uses the QBE compiler backend

if you want more info, check out my github i guess

Recent activity

Re: __builtin_frame_address equivalent a month ago

From Rosie to ~mpu/qbe

Yeah, I suppose. From what I read, in LLVM when you do `alloca` you 
explicitly request a stack slot, so surely allocN in QBE should act the 
same way?

Re: __builtin_frame_address equivalent a month ago

From Rosie to ~mpu/qbe

 > But it is used: it gets returned.

It is? but don't both functions use `mov w0, #0` ie returning 0?

Re: __builtin_frame_address equivalent a month ago

From Rosie to ~mpu/qbe

I think this behavior is actually QBE just optimizing out unused stack 
allocations completely, staring at it for a while. I do wish there was a 
way to prevent this.

Re: __builtin_frame_address equivalent a month ago

From Rosie to ~mpu/qbe

Yeah, it's kinda weird. This is the IR:

```qbe
function w $foo() {
@start
	%a.addr =l alloc4 8
	%tmp =l copy 0
	storel %tmp, %a.addr
	ret 0
}

```

```s

Re: __builtin_frame_address equivalent a month ago

From Rosie to ~mpu/qbe

I seem to have found the issue -- QBE seems to optimize variables deemed 
small enough into general purpose registers instead of pushing them to 
the stack:

```s
mov	w1, #24
bl	_GCAllocator.alloc
adrp	x0, ___internal.elle.__env__@page
add	x0, x0, ___internal.elle.__env__@pageoff
ldr	x0, [x0]
ldr	x0, [x0]
```

vs. what it should be (for the garbage collector to find it as a root)

Re: __builtin_frame_address equivalent a month ago

From Rosie to ~mpu/qbe

That was my original approach because I can do it from the language 
itself so it could just be an stdlib function, but it's not as reliable 
as I'd like. It sometimes fails to find 1/2 pointers (from the example 
outlined above) while __builtin_frame_address always finds both, which 
is strange because I'd expect the portable solution to also work reliably.

Re: __builtin_frame_address equivalent a month ago

From Rosie to ~mpu/qbe

Yep, this works:

```c
void *__internal_get_frame_address() {
     return __builtin_frame_address(1);
}
```

At compile time, I compile this and link with the object. I'm not sure 
why I didn't think of this lol, thank you.

Re: __builtin_frame_address equivalent a month ago

From Rosie to ~mpu/qbe

 >You can rely on your C compiler and write a stub
that wraps __builtin_frame_address(1). This stub
is then easily called from qbe il.

Sorry I only just saw this. That might actually be a simpler way to do 
that, thank you I think that should work.

Re: __builtin_frame_address equivalent a month ago

From Rosie to ~mpu/qbe

Update: I wrote a somewhat automatic runtime thing which automatically 
compiles and links a tiny amount of assembly for the architecture that 
the compiler was compiled on (only aarch64 and x86_64 are supported for now)

```s
.text
.balign 4
.global ___internal_get_frame_address
___internal_get_frame_address:
     mov x0, x29
     ret
```

```s

__builtin_frame_address equivalent a month ago

From Rosie to ~mpu/qbe

Consider the following C function:

```c
#include <stdio.h>

int main() {
     printf("%p\n", __builtin_frame_address(0));
     return 0;
}
```

which prints the stack frame pointer of the current function (using the 
GCC __builtin_frame_address).