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

Implement clang-based scanner #5

Open
ChiefGokhlayeh opened this issue Nov 6, 2019 · 1 comment
Open

Implement clang-based scanner #5

ChiefGokhlayeh opened this issue Nov 6, 2019 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@ChiefGokhlayeh
Copy link
Owner

ChiefGokhlayeh commented Nov 6, 2019

As discussed in #3 (comment), explore possibilities of using libclang's C API. Fortunately, libclang provides Python bindings for their C API.

Experimenting with it demonstrated, that libclang provides deeper lexical fidelity when parsing a C source/header file (i.e. it provides preprocessor tokens before they're expanded). Perhaps this can be used to more effectively work around __asm__(...)-statements, which make direct inclusion of that particular file impossible.

@ChiefGokhlayeh ChiefGokhlayeh added the enhancement New feature or request label Nov 6, 2019
@ChiefGokhlayeh ChiefGokhlayeh self-assigned this Nov 6, 2019
@ChiefGokhlayeh
Copy link
Owner Author

ChiefGokhlayeh commented Nov 6, 2019

On the topic of "impossible headers":

Assume the following header:

#ifndef DRIVER_H_
#define DRIVER_H_

void some_func(void)
{
    __asm__("bkpt");
}

#endif DRIVER_H_

Not that some_func is defined directly within the header file. Note also that __asm__("bkpt"); is not a valid x86(_64) instruction. The compiler will therefore refuse compilation, even if some_func is cleverly knocked out through the workaround stated in In-Header Defined Functions.

The only solution I see is to abandon the "wrapping" philosophy and resort to "banning" the original header. Utilizing libclangs deeper lexical offerings we might be able to "copy" a slimmed down version of the original header and kick out such in-header definitions, while keeping declarations and inclusions intact.

Unfortunately, the same can not be done for illegal instructions inside C macros. Without expanding such a macro in the appropriate context, nobody can tell what its contents mean (they could be virtually anything, so reliably parsing it is effectively impossible). Some more thinking required...

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

No branches or pull requests

1 participant