You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The main problem of OCELOT is that it doesn't work on some C functions. This happens because, in many cases, CDT is not able to get information about the types used (e.g., structs) and the function under test may require the execution of other functions in the same project.
The best chance we have to fix the first problem is to bind it to a specific IDE. At the moment, we use CDT, but we are not tied to Eclipse because we do not use specific Eclipse dependencies.
We could proceed in two directions:
Creation of an Eclipse plugin
Pros: We would reuse most of the code we wrote for instrumentation
Cons: Eclipse is losing popularity and CDT is a pretty old library
Creation of a CLion plugin
Pros: Very good framework for plugin development (I used IntelliJ's, and I assume it is the same)
Cons: We have to re-write most of the instrumentation code
I would be more prone to go for (2), it seems to me that it would make OCELOT more stable, even if the effort is higher. Also, it would help to solve the second problem (see below).
About the problem with dependencies, we could:
Compile the whole project as a static library (e.g., project.a)
Rename and instrument the function under test (e.g. __ocelot_function_under_test)
Run OCELOT including as JNI dependency "project.a" + a simple file just containing the function under test instrumented.
This would speed-up the instrumentation because we need to compile the whole project just once. The main problem with this approach is that we would miss situations in which the function under test calls itself indirectly. For example: FUT_i --> x --> FUT
In this case, x would call the non-instrumented version of the function (which is still in "project.a"), and OCELOT would not count that for coverage. But I think this is not very common.
Of course, there may be other solutions.
The text was updated successfully, but these errors were encountered:
I am not a big fan of Eclipse, but I think that the main problem is the effort needed to develop a CLion plugin. If you manage this effort, I will definitely agree with the second option.
I'd go for the second solution, as Simone suggested!
About the problem mentioned, I think that's just a corner case and it could be ignored at the moment.
The problem with the CLion plugin is mostly due to the rewriting effort, I would say. It should be something like 1.8 KLOC. But I looked at the code, we don't have to rewrite it entirely, we just need to adapt it to the new framework.
The main problem of OCELOT is that it doesn't work on some C functions. This happens because, in many cases, CDT is not able to get information about the types used (e.g., structs) and the function under test may require the execution of other functions in the same project.
The best chance we have to fix the first problem is to bind it to a specific IDE. At the moment, we use CDT, but we are not tied to Eclipse because we do not use specific Eclipse dependencies.
We could proceed in two directions:
Pros: We would reuse most of the code we wrote for instrumentation
Cons: Eclipse is losing popularity and CDT is a pretty old library
Pros: Very good framework for plugin development (I used IntelliJ's, and I assume it is the same)
Cons: We have to re-write most of the instrumentation code
I would be more prone to go for (2), it seems to me that it would make OCELOT more stable, even if the effort is higher. Also, it would help to solve the second problem (see below).
About the problem with dependencies, we could:
This would speed-up the instrumentation because we need to compile the whole project just once. The main problem with this approach is that we would miss situations in which the function under test calls itself indirectly. For example:
FUT_i --> x --> FUT
In this case,
x
would call the non-instrumented version of the function (which is still in "project.a"), and OCELOT would not count that for coverage. But I think this is not very common.Of course, there may be other solutions.
The text was updated successfully, but these errors were encountered: