On Tue, Aug 23, 2011 at 9:05 AM, SF Markus Elfring < [email protected]> wrote:
> 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. Okay. Maybe it's worth taking a second look at AOP if that's the case. > 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? Sorry it wasn't clear to me before that AOP compilers are just generating C code which can be fed into a favorite C compiler. Although I'm still wondering how that works because it would seem to me that if AOP languages are offering their own graphical debuggers then this could mean that they are potentially 'in bed' with a particular compiler. But perhaps this is only of particular concern in the case of wanting to make use of the debugger... which in my case I wouldn't. I need to try out some sort of AOP 'hello world' example, but I had the feeling that it is not designed to bolt onto existing C projects and that the idea is that to use it one must forever use the AOP compiler because of the different AOP syntax. If this is true then it goes against one of my design goals which is to be able to create an automatically instrumented build of any particular C project without change the original source code. > 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? ;-) > Yes :-) The one in one million transactions bugs which only occur at e.g. 50,000 transactions per second even with a fully automated, regression test suite forcing 100% code coverage. In such cases, the debugger isn't very useful. Thanks, Simon > Regards, > Markus >
_______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
