Dan Sheridan wrote: > These two patches are the first of several implementing improved graph > generation for Sparse. Very nice work. I've applied both patches in this series. I also added shebangs to the gvpr scripts and made them executable, so you can just run graph ... | gvpr/return-paths | dot ... I noticed one minor issue: gvpr/return-paths seems to turn some internal edges in functions into dotted-line return paths. Also, unprocessed graphs have now become far more messy; for instance, graphing validation/context.c generates numerous edges to a() and r(). Any way you could prevent these edges from crossing other subgraphs? Any way to make these edges just point to a separate node "a()" and let people look up a() themselves, removing the excess edges? Perhaps with a gvpr script? > Initially, I am dealing with straight-forward > control flow. Forthcoming patches will add program dependency graphs (a > control and data flow representation suitable for program slicing) and > simple pointer alias analysis (for handling indirect calls). I look forward to seeing these future enhancements. Pointer alias analysis would help greatly with many other things in Sparse. > I've tried to keep the C part of the flow graph relatively simple, and > put the hard stuff (like return edges and subgraph processing) in > post-processing scripts. > > Example graph can be seen at > http://www.postman.org.uk/djs52/example.png, generated with > > ./graph validation/context.c | gvpr -f gvpr/return-paths | \ > gvpr -f gvpr/subg-fwd -a good_while3 | dot -Tpng > /tmp/example.png Impressive work. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature
