Debugging Newbie Question

J

John Carron

Hi All,

Can anyone please explain the relationship between the source files,
debug symbols (pdb) and the compiled files please?

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?

And is it true to say that the symbols files are just a 'mapping' between
the source code and the compiled IL?

Any help would be great.

Thanks

John
 
R

Richard Grimes [MVP]

John said:
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
 
J

John Carron

Hi Richard,

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

Regards

John
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Location of .cs files used for debugging 0
Debugging issue 0
Debugging with Web.config 3
Debugging 1
Debugging problems 3
Difficulty debugging WCF service 0
Newbie Question. 2
Debugging Problems on Windows Vista 7

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top