Skip to content
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

Add proper handling of undef values #159

Open
surovic opened this issue Jul 15, 2021 · 1 comment
Open

Add proper handling of undef values #159

surovic opened this issue Jul 15, 2021 · 1 comment

Comments

@surovic
Copy link
Contributor

surovic commented Jul 15, 2021

https://llvm.org/docs/LangRef.html#undefined-values

Relates to #158

@artemdinaburg
Copy link
Contributor

Left a comment on the PR, but putting it here as well:

So I had to read the undefined value description a bit more.

An undef (if not frozen, which we have not run into yet) can take any value. This is not undefined behavior, but an undefined value.

My opinion is that:

  1. This is probably due to some anvill issue, and anvill should definitely have a pass to see if undef leaks out to final bitcode.
  2. We may have undef as a legitimate source into rellic, if, say, the ISA specs for some instruction specify a register is in an undefined state, and then the register is used.
  3. The current behavior (assume that an undef pointer is NULL) is perfectly valid, since it can indeed be NULL.
  4. For this specific PR, we should return a constant integer of 0 of the right bit width (not cast to a pointer, as this is an int value). I will see if I can make the change.
  5. From a correctness and "what does the user expect?" standpoint, I think we should pick a value (say, zero) and emit function call like:
int32_t rellic_undefined_value_int32() {
#pragma error "The input bitcode uses an undefined value. This may not be an error, but it probably is. Uncomment this pragma to achieve recompilable code.
return 0; // any value works here
}

...
int var0 = rellic_undefined_value_int32();
...

The user of the decompiled code can then figure out what they want to do about the undef, and static analysis tools should be trivially able to see that rellic_undefined_value_*() returns 0 (or 42 or whatever we pick).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants