Advanced debugging in code (Debugging API, breakpoints) 
Author Message
 Advanced debugging in code (Debugging API, breakpoints)

I ran across the Debugging API the other day and was e{*filter*}d with the
possibilities it presented, but it seems extremely limited.  There's no
way to set events on arbitrary conditions (ie. breakpoints).  I assume
there must be a way to do this in Win32, but haven't found mention of
anything.  Are there API calls to do this sort of thing, do I have to
write assembly code, or what?  I'm primarily interested in debugging
separate processes.

Sean



Sun, 17 Jul 2005 06:53:37 GMT  
 Advanced debugging in code (Debugging API, breakpoints)

Sean,

Quote:
> I ran across the Debugging API the other day and was e{*filter*}d with the
> possibilities it presented, but it seems extremely limited.  There's no
> way to set events on arbitrary conditions (ie. breakpoints).  I assume
> there must be a way to do this in Win32, but haven't found mention of
> anything.  Are there API calls to do this sort of thing, do I have to
> write assembly code, or what?  I'm primarily interested in debugging
> separate processes.

Are we talking about the managed or unmanaged debugging apis here?
Note, however, that either api is fairly lowlevel, and most things modern
de{*filter*}s do have to be stacked upon them.

--
Tomas Restrepo



Sun, 17 Jul 2005 07:19:35 GMT  
 Advanced debugging in code (Debugging API, breakpoints)

Quote:

> Sean,

>>I ran across the Debugging API the other day and was e{*filter*}d with the
>>possibilities it presented, but it seems extremely limited.  There's no
>>way to set events on arbitrary conditions (ie. breakpoints).  I assume
>>there must be a way to do this in Win32, but haven't found mention of
>>anything.  Are there API calls to do this sort of thing, do I have to
>>write assembly code, or what?  I'm primarily interested in debugging
>>separate processes.

> Are we talking about the managed or unmanaged debugging apis here?
> Note, however, that either api is fairly lowlevel, and most things modern
> de{*filter*}s do have to be stacked upon them.

Unmanaged native C++.  I'm looking for a way to signal the debugging
process and pause the child process if a specific memory address changes
or if a point in the code is reached.

Sean



Sun, 17 Jul 2005 07:46:10 GMT  
 Advanced debugging in code (Debugging API, breakpoints)
Okay, I think I've got part of it.  I can edit the process memory to
replace an instruction with INT 3 to interrupt the process.  Then I
replace this instruction with whatever was originally there and let the
process continue.  If I want that breakpoint to always fire at that
instruction, I have to re-set the INT 3 after execution has passed that
point.  Am I on the right track?  And is there any way I can signal the
debugging process when a memory area has changed, or do I have to poll
the area for changes?


Sun, 17 Jul 2005 08:05:37 GMT  
 Advanced debugging in code (Debugging API, breakpoints)


Quote:

> > Sean,

> >>I ran across the Debugging API the other day and was e{*filter*}d with
the
> >>possibilities it presented, but it seems extremely limited.  There's
no
> >>way to set events on arbitrary conditions (ie. breakpoints).  I
assume
> >>there must be a way to do this in Win32, but haven't found mention
of
> >>anything.  Are there API calls to do this sort of thing, do I have
to
> >>write assembly code, or what?  I'm primarily interested in debugging
> >>separate processes.

> > Are we talking about the managed or unmanaged debugging apis here?
> > Note, however, that either api is fairly lowlevel, and most things
modern
> > de{*filter*}s do have to be stacked upon them.

> Unmanaged native C++.  I'm looking for a way to signal the debugging
> process and pause the child process if a specific memory address
changes
> or if a point in the code is reached.

To expand on what Tomas said, most of what modern de{*filter*}s do is
layered on top of the debug API functions.  The API provides only those
lowest-level facilities that must be provided by the OS - everything
else is up to the de{*filter*}.

For example, to set breakpoints, most de{*filter*}s replace the first byte
of the instruction on which the breakpoint is placed with opcode 0xCC
(int 3).  When encountered, this causes an exception which breaks into
the de{*filter*}.  The de{*filter*} then has to manage restoring the proper
opcode byte (for disassembly, etc). When execution is continued from the
breakpoint, the de{*filter*} single-steps the process, then replaces the
0xCC so that the breakpoint will be hit again, and then resumes
execution.

Memory breakpoints are set by manipulating the debug registers in the
thread contexts of the process being debugged.  Again, when a debug
event occurs, it causes an exception, which results in control being
transferred to the de{*filter*}.

Writing a de{*filter*} is complicated.  Before you go down that path, make
sure there isn't a way to do what you want with the tools that are
already avilable.

You might be able to do what you want using one of the de{*filter*}s from
the "Windows Debugging Tools" package (or the platform SDK, or the DDK -
I'm not sure where all they're included these days).  Some of these
de{*filter*}s are simple text-based console programs that are scriptable.

-cd



Sun, 17 Jul 2005 08:16:45 GMT  
 Advanced debugging in code (Debugging API, breakpoints)

Quote:

> For example, to set breakpoints, most de{*filter*}s replace the first byte
> of the instruction on which the breakpoint is placed with opcode 0xCC
> (int 3).  When encountered, this causes an exception which breaks into
> the de{*filter*}.  The de{*filter*} then has to manage restoring the proper
> opcode byte (for disassembly, etc). When execution is continued from the
> breakpoint, the de{*filter*} single-steps the process, then replaces the
> 0xCC so that the breakpoint will be hit again, and then resumes
> execution.

Thanks!  This is what I needed to know.  From what I've seen of the
win32 debugging api, however, there is no way to single-step the
debugged process.  Is there an easy way to do this?  I'd rather avoid
breaking two lines in a row if I don't have to.

Quote:
> Writing a de{*filter*} is complicated.  Before you go down that path, make
> sure there isn't a way to do what you want with the tools that are
> already avilable.

I'm looking for a way to build rudimentary IPC into an application that
doesn't currently have it.  I thought I might be able to do this by
manipulating memory in the application to get data in and out.  As this
all has to be done on the fly, I can't use a de{*filter*} with a human
interface.

Sean



Sun, 17 Jul 2005 08:40:59 GMT  
 Advanced debugging in code (Debugging API, breakpoints)


Quote:

> > For example, to set breakpoints, most de{*filter*}s replace the first
byte
> > of the instruction on which the breakpoint is placed with opcode
0xCC
> > (int 3).  When encountered, this causes an exception which breaks
into
> > the de{*filter*}.  The de{*filter*} then has to manage restoring the proper
> > opcode byte (for disassembly, etc). When execution is continued from
the
> > breakpoint, the de{*filter*} single-steps the process, then replaces the
> > 0xCC so that the breakpoint will be hit again, and then resumes
> > execution.

> Thanks!  This is what I needed to know.  From what I've seen of the
> win32 debugging api, however, there is no way to single-step the
> debugged process.  Is there an easy way to do this?  I'd rather avoid
> breaking two lines in a row if I don't have to.

Yes.  You have to set the "Trace" (or single-step) bit in the saved
EFLAGS register in the current thread's context.  That will result in
another debug event after the CPU executes a single instruction.  Then
you can re-set the 0xCC and let 'er rip.

Quote:

> > Writing a de{*filter*} is complicated.  Before you go down that path,
make
> > sure there isn't a way to do what you want with the tools that are
> > already avilable.

> I'm looking for a way to build rudimentary IPC into an application
that
> doesn't currently have it.  I thought I might be able to do this by
> manipulating memory in the application to get data in and out.  As
this
> all has to be done on the fly, I can't use a de{*filter*} with a human
> interface.

I suppose then that you don't have access to the program's source code &
cannot change it, yes?  You might consider applying basic hacking skills
to it as well, patching the binary to hook in some new functionality,
rather than doing it at runtime.

One reason that might be preferable is that having a "de{*filter*}" attached
affects the timing of the "debuggee", sometimes significantly.

-cd



Sun, 17 Jul 2005 09:05:26 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Advanced debugging in code (Debugging API, breakpoints)

2. debugging - code not stopping at the breakpoint

3. Helps need on adding debug info to release mode so to debug release code

4. Debugging code linked to non-debug versions of DLLs

5. really advanced DLL debugging questions:

6. debugging Active X DLLs: kinda advanced question

7. Q: Advanced debugging techniques

8. Q: Advanced debugging techniques

9. Debugging problems: Breakpoints were moved in one sourcefile

10. When debug ATL/VB client - breakpoints in ATL project become disabled

11. breakpoints aren't hit when debugging ATL/COM Service(EXE)

12. VC6 remote debugging ignores breakpoints

 

 
Powered by phpBB® Forum Software