CoFlo 0.0.5 Teaser #2: Enhanced Analysis Reports

I’ve uploaded another teaser showcasing some of the work going into the CoFlo 0.0.5 release.  The subject this time is the enhancement of the HTML reports CoFlo generates.  See the live demo of the ongoing work here.

Note:  The live demo works to varying degrees when run under various browsers.  At the moment, both Firefox (16.0.2) and IE9 (32-bit, 9.0.8112.16421) seem to have no issues, while Chrome (23.0.1271.64 m) works to some extent, but for some reason puts some of the CFGs extremely far down on the page.

The goal of this part of the 0.0.5 work is to address a number of the issues present with the current static HTML reports, and to simultaneously provide more dynamic, interactive, and ultimately more useful reports.

Existing Issues

The static reports generated by CoFlo through version 0.0.4 have a number of issues, two of which are:

  1. The Control Flow Graph images, in many cases, are dimensionally extremely large, often not fitting on the screen.
    While work on the control flow graph generation engine will hopefully address this to some extent, it is unavoidable that many CFGs will, by their very nature, be too large to be meaningfully viewable as a static image on a webpage.
  2. All of the images are on a single HTML page.
    The reports are basically a list of <img> tags containing the CFG images of each function in the single index.html file.  This often results in one extremely wide image causing the browser to put a horizontal scroll bar with a very wide “throw” at the bottom of the page, making it difficult to precisely navigate the intermediate-sized CFGs.  Also, having everything on one page makes for a poor user experience regardless.

Addressing the Issues

As I originally saw it, an interim solution which simply scaled any over-wide CFGs to fit the browser window would be more than adequate.  Sure, there’d still be too many of them on one page, but vertical scrolling only would be far less onerous than both vertical and horizontal scrolling, and I could always split things up later into, say, one index.html and the one page per analyzed file.  Furthermore, since this is the 21st century, how hard could this possibly be?  Set a “max-width: 100%” somewhere and we’re golden.

Right?

…right?

Well, as it turns out: wrong.  The first problem I ran into was that scaled PNGs look terrible.  So I switched to SVGs, a vector graphics format, which is both well suited for the task and – after a mere 10 years or so - finally supported in the latest releases of all major browsers.  Perfect!  So now all that’s left to do is set that “max-width: 100%” in a CSS style sheet somewhere, check the results in the major browsers (if only out of an excess of caution, I mean really, what could possibly go wrong), and we’re done…

Wrong again.  Worked as expected in some browsers, but on at least one other which shall remain nameless, it didn’t maintain the SVG’s aspect ratio.  Turns out, that even in the 21st century – i.e. The Future(tm) – there’s no standards-specified way to tell a web browser “If this SVG <object> is wider than the browser window, resize it and maintain its aspect ratio”.  So it was that I found myself entering the world of…

JavaScript

Google as I might, I could find absolutely no way to scale SVGs as I needed to without resorting to doing it manually with JavaScript.  So I read a few tutorials on line (I’ve been around a while and have written code in more languages than is probably healthy for one man, but I’d never crossed paths with JavaScript before) and put my new-found skills to work.  This post is getting long, so I won’t bore you with the details, but in my journey to the live demo, I ran into my fair share of stumbling blocks:

  • The Same-Origin Policy
    Short form: If you point your browser at files on your local filesystem (i.e. not through a server), your browser will block certain actions which it ordinarily wouldn’t.  Need I mention that what is blocked varies wildly between browsers?
  • The Dojo Toolkit
    Really neat and comprehensive JavaScript framework.  Was working great for what I was trying to do until I realized that it’s heart is made of pure AJAX – which runs afoul of – yep – the Same-Origin Policy.
  • There’s not really a standard way to include SVG files into HTML files.
    There are at least three ways which work to varying degrees on different browsers, so I guess that’s something.
  • You have to do a bit of DOM gymnastics to get an SVG’s ”naturalWidth” and “naturalHeight”.

So I settled on jQuery, jQuery UI, and a few other JavaScript libraries, and things are working reasonably well.

As always, thanks for your interest in CoFlo.

Gary R. Van Sickle

Be Sociable, Share!

2 thoughts on “CoFlo 0.0.5 Teaser #2: Enhanced Analysis Reports

  1. can CoFlo generate Control Flow Graph from the Assembly produced by C or C++ ?
    Is there any tool that generates Control Flow Graph from Assembly ?

    • Hi Marshal,

      Unfortunately no, CoFlo currently is C and C-like C++ only. Long-term, I’d like to support more languages, including various assembly languages, and in fact my current work is setting up some infrastructure for that. But any such support is a long way away at this point.

      I’m not aware of a tool that does generate CFGs from assembly, but I wouldn’t be surprised if there are some out there. In some ways it’s an easier task, and I have run across a number of academic papers on the topic (googling something like “decompiling assembly code” should turn up some links).

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>