Skip to content

[cpuid-x86.h] Add MSAN annotations to mark memory as initialized #647

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

Merged
merged 1 commit into from
Jan 12, 2024

Conversation

tkoeppe
Copy link
Contributor

@tkoeppe tkoeppe commented Jan 8, 2024

It is valuable for Clang's MSAN to detect uninitialized memory accesses, but MSAN cannot instrument the explicit assembly, so we have to annotate the effects of the assembly manually.

@sthibaul
Copy link
Contributor

sthibaul commented Jan 8, 2024

MSAN cannot instrument the explicit assembly

It cannot, really? We already explicitly express what values are written through "=x" and "+x"

@tkoeppe
Copy link
Contributor Author

tkoeppe commented Jan 8, 2024

That doesn't appear to suffice. MSAN has to add instrumentation code, and also it doesn't know what the assembly is doing. I think you should be able to reproduce this quite easily with a small toy example that just sets a variable via assembly and returns if form main, and run that with MSAN.

@sthibaul
Copy link
Contributor

sthibaul commented Jan 8, 2024

That doesn't appear to suffice.

Ok, but what I am saying is that it is the wrong place to fix this, since the code is already expressing what MSAN needs to know (actually compilers have always needed it so as to properly integrate inline assembly in the rest of their code).

MSAN has to add instrumentation code, and also it doesn't know what the assembly is doing.

It does know what it needs to know: "+x" tells that the snippet both reads & writes the value, and "=x" tells that the snippet writes the value.

@tkoeppe
Copy link
Contributor Author

tkoeppe commented Jan 8, 2024

Aha, I discussed this with the LLVM team, and it looks like MSAN does recognize outputs. It's only the ebx pointer that needs annotating.

That itself could also be an issue with MSAN, though.

@MaskRay
Copy link

MaskRay commented Jan 8, 2024

Not handling indirect output constraints in inline assembly in a known issue in MemorySanitizer: google/sanitizers#192

llvm/llvm-project#77393 should help this ebx pointer argument (but requires explicit -mllvm -msan-handle-asm-conservative for now).

@bgoglin
Copy link
Contributor

bgoglin commented Jan 9, 2024

FYI, the CI breakage was unrelated, it passes now.

@tkoeppe
Copy link
Contributor Author

tkoeppe commented Jan 9, 2024

@bgoglin Thanks! I was hoping that'd be the case :-)

@tkoeppe
Copy link
Contributor Author

tkoeppe commented Jan 9, 2024

@sthibaul Given that it's unlikely that MSAN will support the ebx case properly out of the box any time soon, would you be willing to reconsider this proposal?

@sthibaul
Copy link
Contributor

sthibaul commented Jan 9, 2024

@sthibaul Given that it's unlikely that MSAN will support the ebx case properly out of the box any time soon, would you be willing to reconsider this proposal?

Yes, but please add the link to llvm/llvm-project#77393 along the call, so we remember why we still put this and know from which llvm version we will be able to drop it.

@tkoeppe
Copy link
Contributor Author

tkoeppe commented Jan 9, 2024

@sthibaul That's done. Note, though, that that PR is not going to enable the effect tracking by default, but only in conjunction with a separate flag, so there's still a bit more to do after that PR lands.

@sthibaul
Copy link
Contributor

sthibaul commented Jan 9, 2024

only in conjunction with a separate flag

AIUI from llvm/llvm-project#77393 having to add the flag will only be temporary

@bgoglin
Copy link
Contributor

bgoglin commented Jan 10, 2024

To be sure I understand, the hwloc side of the PR is complete, the (temporary) flag doesn't require any change in hwloc itself?

@sthibaul
Copy link
Contributor

yes, the flag is only to be used along -fsanitize=memory

@bgoglin bgoglin merged commit 0bf1fe8 into open-mpi:master Jan 12, 2024
@tkoeppe
Copy link
Contributor Author

tkoeppe commented Jan 12, 2024

Thank you!

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

Successfully merging this pull request may close these issues.

4 participants