You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure what a good solution would be here, perhaps once zig has its own assembler it could attempt parsing the assembly on some architectures and figuring out the required stack size, or else error out if that's not possible.
On a related note, the compiler will probably never be able to know the stack size of an external function. Currently this crashes the compiler:
// lets assume this requires 16KB (0x4000) bytes of stackextern"c"fnsome_external_fn() void;
test"@sizeOf(@Frame(...)) for extern functions" {
// this should probably be a compiler errorassert(@sizeOf(@Frame(some_external_fn)) >=0x4000);
}
The expected result should probably be a compiler error.
The text was updated successfully, but these errors were encountered:
he-la
changed the title
Plan to make @Frame work/error on call chain involving inline assembly, extern fns, etc
Plan to make @Frame work/error on call chain involving inline assembly, extern fns, etc?
Feb 4, 2020
When a program uses inline assembly, it drops beneath the async function abstraction and participates directly in machine code. @Frame is not a measurement of stack size; rather it is a struct that contains all the local variables. If inline assembly wants to cooperate with an async function frame then it should use memory of local variables to the function.
For the purposes of #157, it's the same deal. Inline assembly is not taken into account when calculating stack size. If it wants to affect the stack size measurement, then it will need to reference a local variable of an appropriate size, to annotate the possibility of stack space used.
It's planned for external functions and function pointers to have a "required stack size" annotation. External functions will default to something like 8 MiB.
Currently
@Frame
is not able to detect frame requirements imposed by inline assembly:test.zig
:I'm not sure what a good solution would be here, perhaps once zig has its own assembler it could attempt parsing the assembly on some architectures and figuring out the required stack size, or else error out if that's not possible.
On a related note, the compiler will probably never be able to know the stack size of an external function. Currently this crashes the compiler:
The expected result should probably be a compiler error.
The text was updated successfully, but these errors were encountered: