This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: target_read_memory for breakpoints


> 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 ;-).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]