This is the mail archive of the gdb-patches@sources.redhat.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]
Other format: [Raw text]

Re: RFA: Breakpoint infrastructure cleanups [0/8]


Eli Zaretskii wrote:
Date: Fri, 17 Oct 2003 14:38:52 -0700
From: Michael Snyder <msnyder@redhat.com>

Debugging using tracepoints is a totally different process
than debugging with breakpoints.  It's like planning and
setting up a photo or video shoot, going away while someone
else does the filming, then coming back and looking at
the results.


Debugging with tracepoints indeed uses a different paradigm, but
_operations_ on tracepoints are almost identical to those for
breakpoints: they have the same syntax and a very similar semantics.

That's true -- by design.


Like breakpoints, each tracepoint is a trap in some point of code,
designed to do something when the program gets to that point.

_May_ be a trap. That part of the implementation is on the target, and gdb doesn't know how it is implemented.

We're both right -- the interface is very similar, but the
concept and the way it is used is very different.



Asynchronous signals aren't like traps at all.


I didn't mean to say they were. I meant to say that catching forks,
signals, longjmps, and syscalls works by setting traps in some
specific portions of the program's code.

Except for asynchronous signals. I haven't tried real hard to find other exceptions, but that's one.


So it's the same as setting
a breakpoint, we just give the user a convenience feature to ease the
way of specifying the place where to set the trap.

In other words, all these features use breakpoints of some kind, it's
only their use in the higher-level view of the debugging process is
different.  When discussing the syntax and semantics of these
commands, I think the lower-level similarity is what matters, not the
higher-level distinction of their application.

Well, again, the interface may be the same. The implementation may be similar (although in many cases we're actually setting a "mystery breakpoint" at a location the user knows nothging about). But conceptually they are very different.




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