dotnet clr: I really want to see what machine code the JITter is producing for an
undebugged release build. I've discovered that I can call a breakpoint
opcode (INT3) which will allow me to attach a debugger and see a little
bit of what I want but its difficult to navigate.

There's the ngen /debug option, but I can't seem to figure out how to
get ngen to generate the native assembly so that I can attach to it and
see whats going on.

[quoted text, click to view]
|I really want to see what machine code the JITter is producing for an
| undebugged release build. I've discovered that I can call a breakpoint
| opcode (INT3) which will allow me to attach a debugger and see a little
| bit of what I want but its difficult to navigate.
|
| There's the ngen /debug option, but I can't seem to figure out how to
| get ngen to generate the native assembly so that I can attach to it and
| see whats going on.
|
| Any thoughts?

The only possibility is through the native debugger.

Willy.

[quoted text, click to view]

You don't need to compile in debug mode or start under the debugger to
debug the application and view the JITted code. You can attach with
WinDbg and load up SOS (".load sos"), and then use commands like
"!name2ee YourModule.exe YourNamespace.YourClass.YourMethod" to get the
jitted address (once they've been run once), and then
"!u <addressOfJITted-method>" to disassemble the body of the managed
method.

-- Barry

--