Hi Frank
Indeed, one of the most endearing things about the CLR as a
compiler target
is that you get the good debugging experience for free. I
did talk a bit
about this in my book "Compiling for the .NET Common
Language Runtime"
Prentice-Hall, 2002. However, the level of support provided
by ILASM has
improved since the book came out.
There are three kinds of information that *any* debugger
needs: type
information on the structured data, the args/locals of each
activation
record, and line markers in the code. The first two of
these are inherent
in the metadata of managed code, so you only need to add the
line
info. ILASM provides for this by the .line directive.
There are three
levels of resolution. The coarsest is to place markers ---
.line 42 'sourcefile.xxx'
In this case the debugger will highlight the whole line when
you stop at
line 42.
The finest resolution is the format which specifies start
and end line, and
start and end column ---
.line 42,43 : 10,48 'sourcefile.xxx'
In this case, when you stop at this breakpoint you will get
the highlight
from column 10 of line 42 all the way through to column 48
of line 43.
You can use an empty (single-quote) string instead of the
source file name
to imply "same file".
If you want to look at some examples, compile some C# with
/debug and do --
> ildasm /out=file.out /linenum file.exe
and browse the output.
Have fun
John Gough
At 04:02 AM 30/01/2006, you wrote:
>Hello, this is my first post to the list so my apologies
if I ask a
>predictable and often-answered question! (Is there a FAQ
for this list?)
>
>I have begun implementing a subset of Erlang in v2.0 of
the CLR. Just last
>night I ran into the compilation session of this year's
PDC (that is also
>how I found this list). In that session, it was
mentioned that emitting
>basic file line/column info is nearly enough to get the
VS debugger to
>operate with my new language implementation.
>
>Obviously, this sounds great to me! Does anyone have
documentation of what
>I should emit and what further actions I should take to
get the debugger
>working? I have had a hard time tracking down this type
of information. I
>am not looking for 100% of all debugging features (as
measured against the
>debugging features of C#), but any debugging features
for my language
>implementation would be great.
>
>Well, thank you all for listening!
|