Fortran - Slightly OT: Debugger Operation

Author

Slightly OT: Debugger Operation

Gary L. Scott

2006-01-18, 7:03 pm

Hi,

Conceptually, how does a typical debugger application work? I assume
that the compiler produces an executable module with extra information
(a "debug" version) to aid the process. How does the debugger implement
single stepping, breakpoints, etc. (assume MS WinXP). I'm a little

as to how this works on Windows because most debugging I'm
familiar with actually controls the CPU and address bus directly.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

James Parsly

2006-01-20, 7:09 pm

I don't know for sure, but I suspect that somewhere along the line a table
is created that
has the address within the executable where each line of code starts. For
each line that has
the possibility of transferring control it would also have to have a list of
all the lines where you might end up.
The computed goto would be an extreme example.

Single stepping, breakpoints, "run to cursor", all have the common
requirement that the debugged program
must be allowed to run normally until it gets to a specific line of code,
and then the debugger must get control again.
To make this happen, the debugger would replace the code at the targeted
location with code
that wakes up the debugger, saving the original code somewhere so that it
can be restored.
I vaguely remember that Intel processors have a single byte interrupt
instruction that can
be used for this purpose.

So for example, if you were single stepping through your code, things would
work something like this:

1.Debugger is in control, and has your program loaded into memory
2. You hit single step function key. Debugger looks up location within your
code where the next line to
be executed starts, and where the line after that starts (for this
example, lets suppose that there's
only one line we can get to). It does the math to figure out where the
following line is actually located
in memory, and replaces the code there with a single byte interrupt
instruction, storing the original byte
in an internal table.
3. Debugger transfers control to the debugged program at the location where
the next line starts.
4. Debugged program runs one line, when it gets to the start of the next
line it encounters the
interrupt instruction which puts the debugger back in control.
5. Debugger restores the original byte in memory, and waits for the user to
make another command.

"Gary L. Scott" <garyscott@ev1.net> wrote in message
news:11ssib9gsur1s89@corp.supernews.com...
> Hi,
>
> Conceptually, how does a typical debugger application work? I assume that
> the compiler produces an executable module with extra information (a
> "debug" version) to aid the process. How does the debugger implement
> single stepping, breakpoints, etc. (assume MS WinXP). I'm a little
>

as to how this works on Windows because most debugging I'm
> familiar with actually controls the CPU and address bus directly.
>
> --
>
> Gary Scott
> mailto:garyscott@ev1.net
>
> Fortran Library: http://www.fortranlib.com
>
> Support the Original G95 Project: http://www.g95.org
> -OR-
> Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
>
> Why are there two? God only knows.
>
>
> If you want to do the impossible, don't hire an expert because he knows it
> can't be done.
>
> -- Henry Ford

Dave Weatherall

2006-01-21, 3:56 am

On Wed, 18 Jan 2006 13:57:55 UTC, "Gary L. Scott" <garyscott@ev1.net>
wrote:

> Hi,
>
> Conceptually, how does a typical debugger application work? I assume
> that the compiler produces an executable module with extra information
> (a "debug" version) to aid the process. How does the debugger implement
> single stepping, breakpoints, etc. (assume MS WinXP). I'm a little
>

as to how this works on Windows because most debugging I'm
> familiar with actually controls the CPU and address bus directly.

One way of doing breakpoints is to replace the instruction at the
breakpoint with a TRAP or software interrupt. The interrupt hands
control back to the debugger. hardware debuggers do it by comparing
address lines and HALTing the cpu.

--
Cheers - Dave.

glen herrmannsfeldt

2006-01-22, 7:56 am

Dave Weatherall wrote:
> On Wed, 18 Jan 2006 13:57:55 UTC, "Gary L. Scott" <garyscott@ev1.net>
> wrote:

If there is no other way, it is done by interpreting the instructions
one by one. Some processors have a special interrupt that causes
in interrupt after one instruction, specifically for doing single
step. Breakpoints are usually done by replacing the instruction
at the breakpoint with a special instruction to interrupt at that
point, and single step can also be done that way, except for
branches.

S/370 has special mode called PER (program event recording)
with some interrupts that can be useful for debugging
if the OS supplies a way to use them. One will interrupt on
any memory access within a specified range. This can find how
a variable is being modified when you can't otherwise find the
problem.
[color=darkred]
> One way of doing breakpoints is to replace the instruction at the
> breakpoint with a TRAP or software interrupt. The interrupt hands
> control back to the debugger. hardware debuggers do it by comparing
> address lines and HALTing the cpu.

That is probably still used for embedded systems. I do remember
that the Z80 was preferred over the 8080, as it allowed one to
stop the clock, or single step the clock. Many Intel processors have
dynamic logic with a minimum clock speed. Software debugging likely
requires a processor with an interrupt for illegal instruction,
which many smaller processors don't have.

-- glen

Sponsored Links