On Mon, Aug 22, 2011 at 01:33:47PM -0700, 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. That's one example of how I am > imagining on-the-fly instrumentation to work.
Is DTrace <http://en.wikipedia.org/wiki/DTrace> of any use to you? Dave -- David Young OJC Technologies [email protected] Urbana, IL * (217) 344-0444 x24 _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
