Cecil.FlowAnalysis?

[Alex Lyman]

What's the status of Cecil.FlowAnalysis?

I'm able to find it in /trunk/cecil/flowanalysis, but it doesn't seem
to be in /trunk/mcs/class/Mono.Cecil -- is it meant to be compatible
with the mcs/class/ version of Cecil?

[Jb Evain]

Hi Alex,

Yes, it works along with the current Cecil which lives in mcs/class.

Cecil.FlowAnalysis has been developed for the specific needs of db4o,
and hasn't been developed afterwards. The focus shifted to
Cecil.Decompiler afterwards, but its development is paused until I
complete the cecil refactoring (should be a matter of a couple of
weeks now).

--
Jb Evain <j...@nurv.fr>

[Alex Lyman]

Jb,

Is there any chance that the refactoring is happening on a publicly-readable branch?  Is there a wish-list for Cecil.Decompiler?  I've recently come into a metric load of spare time (I was nicked in the second round of layoffs at my old company, and the job hunt seems to have stabilized to only fill about an hour each day), and contributing to Cecil would be a pleasure.

Alex J. J. Lyman

--
--
mono-cecil

To unsubscribe from this group, send email to mono-cecil+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Jb Evain]

Hey Alex,

On Tue, Mar 23, 2010 at 7:34 PM, Alex Lyman <mail.al...@gmail.com> wrote:
> Is there any chance that the refactoring is happening on a publicly-readable
> branch?

I'm keeping the current development private until it reaches Cecil's
feature set. A few people have access to it and are helping testing
it. Good news is that it's almost complete, so with some more tests,
it should be publicly available in a couple of weeks at most.

> Is there a wish-list for Cecil.Decompiler?

Not really. It still have to undergo quite a few changes in the API.
But it has some cool foundations I think.

> I've recently come into
> a metric load of spare time (I was nicked in the second round of layoffs at
> my old company, and the job hunt seems to have stabilized to only fill about
> an hour each day)

I'm sorry to hear that. Good hunting :)

--
Jb Evain <j...@nurv.fr>

[Tedd Hansen]

Hi

I have one wish list item. :)

Some way of knowing the argument stack at any given instruction. (count and
what types in what order)

Specifically I want to be able to inject code to save the current stack,
jump elsewhere for some fun-fun action and then later return to resume the
stack. (Implementing fiber support for .Net assemblies)
Unsuccessfully tried to find if Cecil could currently provide this info, so
I guess it can't.

Br,
Tedd

Hey Alex,

--
Jb Evain <j...@nurv.fr>

--

[Jb Evain]

Hey,

On Wed, Mar 24, 2010 at 11:00 AM, Tedd Hansen <te...@konge.net> wrote:
> I have one wish list item. :)
>
> Some way of knowing the argument stack at any given instruction. (count and
> what types in what order)

There's code in the decompiler (Mono's svn, /cecil/decompiler) to
compute the stack height at any instruction. You can certainly enhance
it to provide type information on top of that.

--
Jb Evain <j...@nurv.fr>

[Daniel Grunwald]

On 24.03.2010 11:00, Tedd Hansen wrote:
> Hi
>
> I have one wish list item. :)
>
> Some way of knowing the argument stack at any given instruction. (count and
> what types in what order)
>

Just this week I wrote code to compute the control flow graph from Cecil
IL Instructions - unlike Cecil.FlowAnalysis, my code also handles
control flow for try-catch and try-finally blocks (the latter are quite
complicated and took a whole day to implement correctly).
Then I'm transforming the instruction to 'register IL' - basically I add
metadata to each instruction specifying variables (registers) as inputs
and outputs. Each stack location is transformed into a variable.
After that, I'm calculating the dominance frontiers on the CFG, and
using that info to transform my register IL representation into SSA
form. I also implemented some trivial SSA-based optimizations like copy
propagation and dead code elimination -- these are primarily meant to
make subsequent analysis easier, not as actual optimizations (the JIT
will repeat them anyways).

The end result I'm working towards is statically checking a program for
NullReferenceExceptions. Basically "code contracts lite" - where lite
should refer both to runtime of the tool (I want to be faster than
Microsofts static contract checking tool) and to the ease of use
(annotate parameters with [NonNull] instead of writing a "contract
class"; automatically infer stuff whenever possible). But then again
it'll be focused on introducing non-nullable variables, and not do
anything else that contracts do.

I don't know how useful my SSA classes would be to someone who wants to
modify IL - I'm focusing on the code analysis part and give up the 1:1
correspondence with IL instructions.
You can take a look yourself - here's the CFG and SSA form for a method
using a foreach loop to sum up the length of all strings in a List<string>:
http://www.danielgrunwald.de/coding/null/ForEach.cfg.png (green edges
aren't control flow edges but represent dominance)
http://www.danielgrunwald.de/coding/null/ForEach.ssa.png (ldloca
instructions are eliminated where possible because SSA form can't be
used with them)
The code is a work is progress, but I'm planning on making the CFG and
SSA code available as open-source code when it's done.

Daniel

[Jb Evain]

On Wed, Mar 24, 2010 at 2:49 PM, Daniel Grunwald
<dan...@danielgrunwald.de> wrote:
> You can take a look yourself - here's the CFG and SSA form for a method
> using a foreach loop to sum up the length of all strings in a List<string>:
> http://www.danielgrunwald.de/coding/null/ForEach.cfg.png (green edges
> aren't control flow edges but represent dominance)
> http://www.danielgrunwald.de/coding/null/ForEach.ssa.png (ldloca
> instructions are eliminated where possible because SSA form can't be
> used with them)
> The code is a work is progress, but I'm planning on making the CFG and
> SSA code available as open-source code when it's done.

Pretty cool!

--
Jb Evain <j...@nurv.fr>

[Tedd Hansen]

Hi

Could use some input on
http://teddhansen.wordpress.com/2010/03/20/bug-in-mono-cecil/
Is it a bug? If not, how do I ensure correct pos?

Br,
Tedd

[Jb Evain]

Hey,

I added a comment on the blog when this was posted, but somehow it got
removed. It's not a bug, you're injecting too much code into a short
form branch.

If you don't want to deal with it manually, call:

method_body.Simplify ()

before instrumenting. That will transform all short forms to normal
forms. And when're you're done you can call:

method_body.Optimize ()

to turn them back to short forms if possible.

Here, “bug” is gone.

--
Jb Evain <j...@nurv.fr>

[Tedd Hansen]

Wow.. That simple? Thanks! :)

Comments are moderated I guess, and my inbox would make most db admins
scared - so it probably got lost in the unread category.

Br,
Tedd

-----Original Message-----
From: mono-...@googlegroups.com [mailto:mono-...@googlegroups.com] On
Behalf Of Jb Evain
Sent: 27. mars 2010 00:31
To: mono-...@googlegroups.com

Subject: Re: [mono-cecil] Bug?

Hey,

method_body.Simplify ()

method_body.Optimize ()

Here, "bug" is gone.

--
Jb Evain <j...@nurv.fr>

--

[Tedd Hansen]

Hi

Do you have a link where I could read about this? (or could you explain
quickly?) :)
I added them around my method processing and it works fine. PEVerify seems
happy (except for the 19 stack-related errors I now have;)).
Now my next step is to keep track of the argument stack. You mentioned
Mono.Decompiler for that, will look into it.

Br,
Tedd

-----Original Message-----
From: mono-...@googlegroups.com [mailto:mono-...@googlegroups.com] On
Behalf Of Jb Evain

Sent: 27. mars 2010 00:31

Hey,

method_body.Simplify ()

method_body.Optimize ()

Here, "bug" is gone.

--
Jb Evain <j...@nurv.fr>

--