QEMU: safe linking of extern "C" declarations #1810
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Declared functions in
extern "C"blocks are not necessarily checked at link-time if the symbols are not necessary during compilation (unused symbols).Some symbols could be declared without any definition and still compile correctly.
Someone had this issue with
libafl_qemu_trigger_breakpointbeing declared in LibAFL without a definition in QEMU.Calling the wrapper function in a fuzzer resulted in a linker error.
With the new macro
extern_c_checked!, it is possible to declare C symbols and still get an error if there is no definition.It relies on a nightly feature, and thus will only trigger in a nightly build.
Stable builds will work as before.
It is mainly useful to catch those kinds of errors early in the CI.