2012/5/1 Christopher Li <sparse@xxxxxxxxxxx>: > On Tue, Apr 24, 2012 at 2:54 AM, Konrad Eisele <konrad@xxxxxxxxxxx> wrote: >> Hi, I'd like to extend sparse so that I can preserve a >> dependency tree that goes from c parse entities all >> the way down to single tokens. There are several places >> this can be useful: > > Sorry for the delay. I take a some time to think about this problem. > > May I ask some high level questions? I am trying to understand why > this this token level dependency is useful. One alternative is that, > you do a per-processor stage on the source file. Then you have one > big post processed source. The current sparse can run on that processed > source file and get all the symbol dependency. > > Because each symbol has "pos" and "endpos" member. You only need > to recursively walk the ctype of the symbols you can get the shrink version > of the source code. The draw back with that is, all the macro has been > expended, you will not able to see the macro names etc. But this is the point. All macros are expanded. They disappear completely in the pre-processing step. There is no tool at all right now that preserves the macro-dependency. Even in IDEs like Eclipse you have tools to show macros expansions, but you have no tool to show you in a simple way for i.e.: #define a #ifdef a #define b 1 #endif that "#define b 1" is dependent of "#define a" even the "#ifdef a" is lost and you have to deduce it yourself from the #line comments. I think not very many people know really how (not where) i.e. "size_t" gets defined. There are too many "#ifdef" cases around, too many #include. > > Also, if you change the source file, the shrinking process has to be redone > because it might use new macros. So the shrinking + compiling is not > necessary a saving compare to directly compiling without the shrinking. > I figure you might have a slightly different usage module in mind to justify > the shrinking. Please help me understand how you intend to use it. Yes that is true. Still, for a fixed configuration in most cases you can achieve a speedup. Also you would have a tool to really benchmark source that doesnt draw in too much dependency. > > I think if the source file doesn't need pre-processing. Sparse can do symbol > dependency already. What you really want is actually being able to back > trace in the pre-processing stage, what macro has been expand and what > is the original form on the expanded value. The information for this is in "struct macro_expansion" of the patch and one can build aroung it a trace of the macro expansion. I've done that with a patch for gcc and could do it for sparse also. A example is at: http://cfw.sourceforge.net/htmltag/init_32.c.pinfo.html source at : http://cfw.sourceforge.net/htmltags.html i.e. go in init_32.c.pinfo.html to mark_rodata_ro() and click on virt_to_page (). A help in in the left pannel. -- Konrad > > Chris > -- > To unsubscribe from this list: send the line "unsubscribe linux-sparse" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
