The idea is however not to have to use a special C compiler to obtain the on-the-fly debug instrumentation (read: 'crosscutting concern' in AOS speak), but to compile with any regular C compiler.
The other AOP tools may be just special front-ends for your usual compiler.
It would also allow more complicated forms of instrumentation if the source code is modified by adding non-intrusive comments which influence the instrumentation process.
Comment adjustments are also changes which can affect data positions (and their potentially different processing) in comparison to original source files.
What I don't like about the AOS way is that the syntax of the code changes and I need to use a different compiler.
But I see still a need for an extra tool which transforms expressions from pointcut languages into instructions for the specified target language. The semantic patch language (Coccinelle's SmPL) can also be tried out for this use case.
I want to have my same old code and compiler and just instrument it on the fly.
That's the purpose of tools from the area of aspect-oriented programming, isn't it?
No, I'm not. In fact, I'm going down the instrumentation path in order to avoid the use of any kind of debugger.
I hope that the added advice will not introduce unexpected behaviour. Otherwise, you will need to distinguish the code sources a bit more.
The idea is that the instrumentation itself provides a human friendly, hierarchical log of everything that happens at run-time including all info I need to debug any problem.
Technical challenges will occur if several aspects will be weaved in the code at the same place (join point).
Especially problems involving threaded code or high performance event based systems where debuggers often don't help in the debugging process :-)
Are you concerned about heisenbugs? ;-) Regards, Markus _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
