Re: Debugging Newbie Question

Hi Richard,

Thanks for taking the time for the thorough explanation. It was a
great help.

Regards

John

"Richard Grimes [MVP]" <read my sig> wrote in message
news:ep1MD1dcFHA.1152@xxxxxxxxxxxxxxxxxxxxxxx
> John Carron wrote:
>> Can anyone please explain the relationship between the
>
>> source files,
>
> These are text files that contain the high level language that you want
> compiled. The CLR does not understand this source code and so before it
> can be used the source code must be compiled. ASP.NET confuses things a
> little because it appears that you are providing source code for ASP.NET,
> however, ASP.NET will compile your page's source code and cache the result
> in a location that is not immediately obvious.
>
>> debug symbols (pdb)
>
> When you compile a debug build (or a release build with symbols, which
> I'll come to in a moment) your assembly will be marked as being
> 'debugable'. You source code will be compiled to intermediate language
> (IL) which the runtime will compile to x86 when the assembly is executed.
> 'debugable' means that the runtime will not optimise the x86 code it
> creates, and it will also track the objects that your assembly creates. It
> does this so that a debugger can attach to the code and allow you to step
> through and view the objects. A release mode assembly will not be marked
> as 'debugable' and so the runtime will optimise the x86 it creates from
> the IL and it will not track objects. You can change how the runtime does
> this with an INI file (yes, its one of the few INI files in .NET).
>
> When you debug your code, the debugger will have IL and x86 created from
> the IL. It will know where in the x86 the execution is, and can work out
> where in the IL that is (the VS debugger does not show IL, unfortunately).
> But it does no know what source code created the IL nor where in the
> source code the execution point is. This is what the dbg file is for. It
> indicates the line number and the source file. The debug build assembly
> will have a full path to the symbol file, but if you give the debug build
> assembly to a co-worker they will not necessarily have the same folder
> structure. The debugger will use the full path given in the assembly, or
> it will look in the same folder as the assembly. In addition it will look
> for the symbol file on a symbol server if you have set it up to use a
> symbol server. If the debugger cannot find the dbg file in any of these
> locations then you'll not be able to step through source code. The Visual
> Studio debugger Modules window will indicate if the debugger cannot find
> symbols and allow you to browse for them.
>
> Typically symbols are most useful for debugging, but they do have uses in
> release mode assemblies. For example, the Exception object will have
> information about the location of the code that threw the exception, in
> debug mode this has source file and line information (which is obtained
> through the StackTrace class), this information comes from the symbol
> file. In release mode this information is not available because symbol
> files are not usually available. You can compile your code with
> /debug:pdbonly which will create a pdb for the release mode assembly. You
> won't be able to step through the code with a debugger, but Exception will
> list source file, line information.
>
>> and the compiled files please?
>
> Source files are compiled to intermediate language, and when the runtime
> runs the code in the assembly it will just in time compile the IL to x86.
> Just in time means that the IL is compiled on a method by method basis
> (not the entire assembly as I heard a Microsoft RD tell a conference
> audience, once) as those methods are called. Once a method is JIT compiled
> the x86 is cached in memory and the next time the method is called in this
> run of the process the cached x86 will be used.
>
>> I'm a little confused as to what should be where? For example if I
>> wanted to remotely debug an application should the target machine
>> have the debug symbols deployed to it? or should I have the symbols
>> locally?
>
> The symbols should be on the local machine, where the source files are.
> The local debugger will load them for you.
>
>> And is it true to say that the symbols files are just a 'mapping'
>> between the source code and the compiled IL?
>
> Yes, that's one way of looking at it.
>
> Richard
> --
> www.richardgrimes.com
> my email evpuneqt@xxxxxxxx is encrypted with ROT13 (www.rot13.org)
>
>


.

Relevant Pages

  • RE: debugging dynamic code
    ... Cordbg.exe that ships with the framework SDK (including source code I ... the debugger must be inside my app, so iI need to have a debugger that dubug ... depends on how you are referencing your dependant assemblies. ... compile it and debug it. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Debugging Newbie Question
    ... The CLR does not understand this source code and so before it ... ASP.NET, however, ASP.NET will compile your page's source code and cache ... the debugger will have IL and x86 created from ... in release mode assemblies. ...
    (microsoft.public.dotnet.faqs)
  • RE: debugging dynamic code
    ... Cordbg.exe that ships with the framework SDK (including source code I ... the debugger must be inside my app, so iI need to have a debugger that dubug ... depends on how you are referencing your dependant assemblies. ... compile it and debug it. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Compilation
    ... > compile and run my project it take a long time to start running, ... > becuse the jits compilers. ... This lag time increases the more assemblies ... If you're not talking about starting from the debugger but just about the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: C++/TCL Need Solution to Compile Error c2784
    ... There's always the "Platform SDK" from MSDN if you need the window.h stuff, ... Since I'm using the Command Prompt rather than the GUI to compile the ... I then tried to compile your source code and I kept getting the same ...
    (comp.lang.tcl)