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

OCELOT problems and IDE plugin development #5

Open
intersimone999 opened this issue Jun 7, 2017 · 3 comments
Open

OCELOT problems and IDE plugin development #5

intersimone999 opened this issue Jun 7, 2017 · 3 comments

Comments

@intersimone999
Copy link
Collaborator

intersimone999 commented Jun 7, 2017

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:

  1. 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
  2. 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:

  1. Compile the whole project as a static library (e.g., project.a)
  2. Rename and instrument the function under test (e.g. __ocelot_function_under_test)
  3. 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.

@dardin88
Copy link
Collaborator

dardin88 commented Jun 7, 2017

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.

@giograno
Copy link
Collaborator

giograno commented Jun 7, 2017

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.

@intersimone999
Copy link
Collaborator Author

intersimone999 commented Jun 7, 2017

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.

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

No branches or pull requests

3 participants