-
Notifications
You must be signed in to change notification settings - Fork 165
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
fix: multiple definitions for scap_engine_handle #1889
fix: multiple definitions for scap_engine_handle #1889
Conversation
Please double check driver/API_VERSION file. See versioning. /hold |
/milestone 0.18.0 |
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.
This PR is exactly the reason why I went with SCAP_HANDLE_T
;) The casts it introduces are ugly af, though I agree that if SCAP_HANDLE_T
breaks LTO, we should get rid of it.
But please try to make the (inevitable) casts a bit easier on the eyes :)
56143ba
to
894642a
Compare
LGTM label has been added. Git tree hash: 23511d387de91315465b39b00e1fe4cc03e0dc0a
|
We likely need a rebase for the CI to pass. |
894642a
to
4e5f579
Compare
Thanks @incertum, I've rebased. Though I think there's some kind of issue that causes build problems in some scenarios. I will have to make time and sort them out. |
Perf diff from master - unit tests
Perf diff from master - scap file
Heap diff from master - unit tests
Heap diff from master - scap file
|
Signed-off-by: Federico Aponte <[email protected]>
Signed-off-by: Federico Aponte <[email protected]>
4e5f579
to
f0346c0
Compare
Perf diff from master - unit tests
Perf diff from master - scap file
Heap diff from master - unit tests
Heap diff from master - scap file
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1889 +/- ##
========================================
Coverage 50.98% 50.98%
========================================
Files 310 310
Lines 39612 39612
Branches 17455 17707 +252
========================================
+ Hits 20197 20198 +1
- Misses 14338 14349 +11
+ Partials 5077 5065 -12 ☔ View full report in Codecov by Sentry. |
I've recently rebased and now the required CI stages are passing. There are still some broken stages, but I can't see how they could be related to this PR. The round of approvals need to restart after the rebase. Could anyone please review? cc @gnosek |
LGTM label has been added. Git tree hash: b5ffbecf0cb811faf57f2753fd8fd56060e667f4
|
Not sure whom to go to for soliciting the needed second review. Can anyone help, please? |
@hbrueckner |
/unhold |
Not sure if it will merge, @LucaGuerra mind checking as I am offline now... |
Kind bump, why is this stuck and not merging? @falcosecurity/libs-maintainers thanks! |
Perf diff from master - unit tests
Perf diff from master - scap file
Heap diff from master - unit tests
Heap diff from master - scap file
|
/approve pretty please? |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: federico-sysdig, gnosek The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind cleanup
Any specific area of the project related to this PR?
/area build
Does this PR require a change in the driver versions?
No
What this PR does / why we need it:
Class
scap_engine_handle
is defined once in its header file, but has a single pointer data memberSCAP_HANDLE_T* m_handle
that contains a macro that changes depending on what source file is including it. This is by design, the idea being that it is a sort of hierarchy of classes that share the same functions. However this is not without problems as if one tries to enable link-time optimization (LTO) the linker presents an error that the one-definition rule (ODR) has been broken.This PR solves the issue by using a generic
void*
for the data member and using a cast to the appropriate type each time is is used in a function. This is possible as manipulating functions are specialized for each type, so knowledge of the type is available.The technique sacrifices somewhat the "beauty" of the previous approach: each cast is syntactically "ugly", but saves the ODR and overcomes linker errors when LTO is enabled.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: