There is no left redzone for global variables, so the underflow of the first variable couldn't be caught.
This patch creates a zero-sized array before the first variable so the underflow of it could be observable.
Details
- Reviewers
MaskRay condy zsrkmyn eugenis vitalybuka - Group Reviewers
Restricted Project
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
You are adding a new global to every translation unit.
- Private linkage would not allow them to be merged, this can have significant binary size and RAM overhead.
- There is no guarantee that any of these globals will end up to the left of any sanitized globals. With -fdata-sections, the linker is free to reorder.
- It is also not referenced from anything, so -gc-sections is likely to kill it.
It looks like this will only work in very limited circumstances.
Do you suggest linkonce linkage?
- There is no guarantee that any of these globals will end up to the left of any sanitized globals. With -fdata-sections, the linker is free to reorder.
- It is also not referenced from anything, so -gc-sections is likely to kill it.
It looks like this will only work in very limited circumstances.
Since it's limited, perhaps making it opt-in is a better choice. -asan-global-underflow or something else.
I think it is too hit-and-miss to add even under a flag. It's just not the right approach - but I also don't know what the right approach would be.
Perhaps adding a small left redzone for all globals and reducing the right redzone to keep the total size under control? This way when most globals are instrumented we get approximately the same amount of redzone between any 2 of them, but also a little on the left of the first one.