-
Notifications
You must be signed in to change notification settings - Fork 101
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 frontend support for some constructs used in the Linux kernel #1798
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer the handling of the builtin offset to be done in the adjust code, but I guess we'll loose the information about the node, so LGTM
Thanks, @fbrausse. Could you please run this PR over the SV-COMP benchmarks? |
Indeed it would be better to have this as a separate exprt, not just in order to move it to the adjuster, but also because basically we already have this functionality implemented in the function compute_pointer_offset(). In addition, as the dynamic offsetof isn't handling the C++ base class member case right now, we could factor it out into a separate method so the C++ frontend can override it. Can we leave that for another PR, though? I'll add a TODO. |
Yeah, and I think we merge base class methods/attributes to derived classes
in our irep, so it might be tricky to get that working on
compute_pointer_offset()
Em qui., 25 de abr. de 2024 às 10:27, Franz Brauße ***@***.***>
escreveu:
… I would prefer the handling of the builtin offset to be done in the adjust
code, but I guess we'll loose the information about the node, so LGTM
Indeed it would be better to have this as a separate exprt, not just in
order to move it to the adjuster, but also because basically we already
have this functionality implemented in the function
compute_pointer_offset(). In addition, as the dynamic offsetof isn't
handling the C++ base class member case right now, we could factor it out
into a separate method so the C++ frontend can override it. Can we leave
that for another PR, though? I'll add a TODO.
—
Reply to this email directly, view it on GitHub
<#1798 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKEJH2IJHVAOETZGWOFGULY7EAFFAVCNFSM6AAAAABGYXNBCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZXGE4DAMZZHA>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
--
Mikhail R. Gadelha, Ph.D.
|
a545a5c
to
77f3df8
Compare
Master:
This PR:
|
Thanks for submitting this PR, @fbrausse. |
This PR adds a new command-line option
--include-file
mapping to the-include
option for Clang (also supported by GCC), which the kernel uses to include certain headers before the actual source code being translated. For now I'm testing this ondrivers/cxl/pci.c
via the following command line, corresponding to the (relevant) flags used by kernel's build system itself:Additionally clang-c frontend support for features used in that driver (and its included headers):
With these changes, I'm now finally getting
i.e., the C frontend handles all constructs in the unmodified kernel's CXL driver's "pci.c" file.