views:

62

answers:

1

is it a bug? here is the code

static void Main(string[] args)
{
   fun1();
}
static void fun1()
{
  fun2();
}
static void fun2()
{
  throw new Exception("test exception");
}

build with the above option in VS 2008, with Optimize option not selected and Build advanced options debug info select pdbonly and check the stacktrace.

let me know u guys experience the same

A: 

Yes, using /debug:pdbonly is enough to convince the compiler that its okay to inline methods. It generates a different [DebuggableAttribute] into the assembly:

.custom instance void [mscorlib]System.Diagnostics.DebuggableAttribute::.ctor(valuetype [mscorlib]System.Diagnostics.DebuggableAttribute/DebuggingModes) = ( 01 00 06 01 00 00 00 00 )

Where /debug:full produces:

.custom instance void [mscorlib]System.Diagnostics.DebuggableAttribute::.ctor(valuetype [mscorlib]System.Diagnostics.DebuggableAttribute/DebuggingModes) = ( 01 00 07 01 00 00 00 00 )

If this is a problem, you'll need to explicitly disable inlining like this:

using System.Runtime.CompilerServices;
...
    [MethodImpl(MethodImplOptions.NoInlining)]
    static void fun1() {
      fun2();
    }
Hans Passant
This is strange that optimize- does not have any meaning when pdbonly debug mode is selected. If that is the case microsoft must document this under optimize help section
Krishna Prasad
Who would ever need to post to a forum if they did that?
Hans Passant
Moreover its not the compiler which inlines the methods - its at runtime JIT does that job. Compiler just adds the attributes to instruct JIT to do the inlining
Krishna Prasad
Thats true - anyways i assume that the pdbonly takes preference than optimize for now :)
Krishna Prasad
Meh, the JIT always inlines when it can. Unless explicitly told not to by attributes.
Hans Passant