On Mon, 22 Aug 2011, Simon wrote: > On Mon, Aug 22, 2011 at 12:40 PM, Julia Lawall <[email protected]> wrote: > > > On Mon, 22 Aug 2011, Simon wrote: > > > > > On Mon, Aug 22, 2011 at 10:44 AM, SF Markus Elfring < > > > [email protected]> wrote: > > > > > > > > I'd like to have a sort of C equivalent to this Perl module which > > > > > can do 'round trip' parsing of Perl source code into a structured, > > > > > hierarchical format, and back into Perl source code: > > > > > http://search.cpan.org/~adamk/PPI-1.215/lib/PPI.pm > > > > > > > > How do you think about the applicability of tools like the following > > for > > > > your > > > > use case? > > > > - OpenGrok > > > > - cscope > > > > - LXR Cross Referencer > > > > > > > > > > I have looked at those tools and dismissed them because the info they > > > provide does not appear detailed enough to e.g. exactly re-create the C > > > source file in question; so called round trip parsing. And some of them > > like > > > OpenGrok are quite heavy weight in terms of what you need installed to > > make > > > it do its regular job. The only two possibilities that I have come up > > with > > > so far are Coccinelle and maybe clang (but I'm no sure yet how to make it > > > give up its C tree with or without compiling fully). > > > > > > More about what I want to achieve: Whereas a tool like Coccinelle allows > > > humans to come up with patches to make changes to source files, I would > > like > > > software to be able to patch C sources on the fly. For example, I might > > have > > > a set of C source files which compile and run perfectly fine. My build > > > system might allow me to create a release build and a debug build. I > > could > > > permanently instrument the C source with macros which only get compiled > > into > > > the debug build (this is a great technique which I use today but the only > > > main downside is that it makes the source code more voluminous because of > > > all the instrumentation). What if the instrumentation could be added > > > on-the-fly? I.e. the build system generates a new foo.c file just for the > > > debug build. In this case I would get the best of both worlds; slim > > looking > > > source files and 'permanent' (now in the sense that it can be > > automatically > > > regenerated) debug instrumentation. In order to automatically add the > > debug > > > instrumentation to the debug foo.c file then my script needs to know all > > > about the original foo.c file. It's also important that the extra > > > instrumentation added does not change the line numbering otherwise it > > will > > > be difficult for me to match either compiler errors or run-time assert > > line > > > numbers with the original foo.c file which is the only file that I would > > be > > > editing for development. Does this make any more sense now? > > > > What I proposed with adding comments will change the line numbers. I > > guess one could use /* */ comments. But it will still change the column > > numbers... > > > > But why not let Coccinelle do the instrumentation for you? > > > > That wouldn't be a problem to let Coccinelle do the instrumentation for me. > However, let's say that I want to do the following refactor: Use case: For > every function definition in a C source file, rename it to > shadow_<function_name>, create a new function name called <function_name> > which has the same parameters and result, and then add a unique body to each > new wrapper function. The unique body will contain debug code for run-time > instrumentation of individual function parameters as well as assert > statements before calling the original function. The patch file file spatch > would have to contain a unique function body for each new function created. > So my script could generate the patch files and function bodies but in order > to do so then the script needs to understand the C source file as an > abstract syntax tree so that it can easily iterate through all the functions > in the C source file and their parameters.
Coccinelle can do this refactoring. On hte other hand, it pretty prints the generated code, so the new functions will necessarily cause the line numbers to change. > That's one example of how I am > imagining on-the-fly instrumentation to work. Another example was the enum > example earlier in this thread. Here the unique function body might call > different debug helper functions which have also been created on the fly, > such as a helper function for enum to text string. This could be made to work, but it doesn't now. > As another example, I > imagine brief, comments, to the right of the source lines, in the original > source code having an own format and getting automatically converted into > debug instrumentation lines. It is possible to add comments, but at present their contents must be staticly specific, so this would not work for you either. julia _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
