This is the mail archive of the gdb@sourceware.org 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] |
Date: Fri, 16 Sep 2005 07:00:27 -0700 From: Stan Shebs <shebs@apple.com> Cc: gdb@sources.redhat.com
it's clear that a full-blown handles-every-situation implementation will require a huge amount of kernel hacking in addition to the GDB part. I don't want to get into a situation like that of tracepoints, where the feature ultimately falls by the wayside because it's too narrow in applicability and implementation.
What features can be implemented without hacking the kernel?
If you limited reversing to designated regions, and single-stepped every instruction in the range, collected the exact data changes (by disassembling the instructions) and only allowed examination rather than re-executing from any given point, all that just needs existing GDB machinery. Is it useful? At least somebody thinks so, because I just described how the omniscient debugger works (using Java bytecodes instead of machine instructions).
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |