-
-
Notifications
You must be signed in to change notification settings - Fork 624
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
#max_field_align(4)
on MINIDUMP_EXCEPTION_INFORMATION
misbehaves
#4491
Comments
#max_align(4)
on MINIDUMP_EXCEPTION_INFORMATION
#max_field_align(4)
on MINIDUMP_EXCEPTION_INFORMATION
misbehaves
Just a thought, but this may be because this condition needs to be changed to also apply when the struct has max_field_align: Odin/src/llvm_backend_utility.cpp Line 1203 in d118f88
|
No luck with this dummy diff, unfortunately :(
I see it's used to emit unaligned reads but it seems to be a problem that the |
This is an example C program demonstrating the behavior we desire. #include <stdio.h>
struct __attribute__((packed, aligned(4))) XYZ { int x; void *y; int z; char w; };
int main(void) {
struct XYZ xyz = {1, (void *)2, 3};
xyz.y = (void *)4;
printf("Hello %d %p %d %zu %zu\n", xyz.x, xyz.y, xyz.z, sizeof(xyz), _Alignof(struct XYZ));
return 0;
} The declaration of the struct is like this in IR And then the IR proceeds to specify the alignment for each store and load similar to what we do right now (which is a tad bit annoying, but it is what it is)
So it's along the same lines of setting the struct to be packed. Changing the metadata to |
Yes, it seems that this diff at least makes the test case succeed again. More work needs to be done to make sure that padding is correct for fields and that loading/storing fields from/to the struct is aligned the way we want, which should (hopefully) be reasonable after seeing how
|
Context
When working on #4474, changing
#packed
to#max_field_align(4)
causes incorrect stores to fields to be emitted and for those stores to be read incorrectly byfmt.printf
in turn. Because one of the fields inmdei
was a pointer when%v
was used, a crash happened shortly after the incorrect read.odin report
output:Expected Behavior
Expect no crash and for this to be the output
Current Behavior
Odin code is crashing when using
fmt.printf
on themdei
If
mdei
is replaced with0
, it fails in a manner similar to #4407Failure Information (for bugs)
Please help provide information about the failure if this is a bug. If it is not a bug, please remove the rest of this template.
Steps to Reproduce
git pull
onmaster
to ensure you have up-to-date sourcesFailure Logs
This is a picture of the program crashing when debugging in Visual Studio which contains the information about the access violation.
If
mdei
is replaced with0
, it does not crash and has similar output to #4407The text was updated successfully, but these errors were encountered: