This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: target_read_memory for breakpoints
- To: "Sharath Kumar" <sharathibm at theglobe dot com>
- Subject: Re: target_read_memory for breakpoints
- From: Jim Kingdon <kingdon at redhat dot com>
- Date: 08 Mar 2000 06:44:22 -0800
- CC: gdb at sourceware dot cygnus dot com
- References: <GAMLDEKNADAJKAAA@theglobe.com>
> which in turn calls - "current_target.to_xfer_memory".
Which is set in init_child_ops in inftarg.c to
infptrace.c:child_xfer_memory which in turn calls ptrace() (see the
ptrace() manpage supplied with most unices). This is just writing
memory - no breakpoint-specific code here.
> I actually want to know the implementation of "hitting of the
> breakpoint" and then "continuing after the breakpoint". (for intel
> pentium arch.)
Hitting the breakpoint: see
DO_VM86_ERROR( 3, SIGTRAP, "int3", int3, current) in
/usr/src/linux-2.2.12/arch/i386/kernel/traps.c (int3 is a breakpoint
instruction) or equivalent for other kernels. The kernel then tells
GDB about this to GDB via wait() (see infrun.c:wait_for_inferior in
GDB; the call to wait() is followed by a lot of code in which GDB
tries to distinguish breakpoints, single stepping, hardware
watchpoints and other such events).
Continuing: see resume() in infrun.c which does the target vector
thing to get to infptrace:child_resume() which then calls ptrace with
PT_CONTINUE (note that GDB has also called target_xfer_memory to pull
out the breakpoint in the meantime).
Anyway, thanks for taking the effort to understand. We'll have you
hacking up GDB from here to left in no time ;-).