-
Notifications
You must be signed in to change notification settings - Fork 44
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
Stack memory tracking improvements #573
Conversation
Fixes vbpf#566 Signed-off-by: Dave Thaler <[email protected]>
Does EBPF runtime guarantee little-endianness? |
No. But the CI/CD tests, as well as the ebpf-for-windows runtime, today only runs on little-endian machines. |
So endiannes needs to be a parameter, no? |
Agreed. I may or may not get to this for a couple of days though, busy at a convention right now. |
Looking into this now. stack.yaml already (before this PR) has a bunch of test cases that assume little-endian. That said, i am working on changes that allow supporting both, but that would be needed even without this PR. |
@dthaler this needs to be reopened |
I'm still working on changes for big-endian systems. Just slow because I have a bunch of other things going on besides this but I should finish it in the next two weeks and will open an endianness PR then. |
Example before instruction:
The instruction then sets
Prior to this PR, after instruction, the state of
s[504...507]
is known but the state ofs[508...511]
is not.Since it was a singleton number before the instruction, it is possible to retain knowledge of it by
splitting it off from
s[504...511]
rather than forgetting everything about those bytes. This resultsin greater precision, and will allow a number of conformance tests, like lock_add32.data in PR #558 to pass exactly instead of going to TOP.
Fixes #566