|
From: Greg P. <gp...@ap...> - 2009-08-12 21:21:19
|
On Aug 12, 2009, at 2:06 PM, Philippe Waroquiers wrote: >> Here is the last message I could find on the subject: >> http://sourceforge.net/mailarchive/message.php?msg_id=001301c871b1%249ef18e80%240202a8c0%40soleil >> the progress appears to have stopped 1.5 years ago :-( > > I started this gdb stub a while ago now, but stopped because a more > complete > gdb stub was implemented as part of a valgrind port to MacOS, which > has now > been integrated in 3.5.0 I didn't include that gdb stub with the Mac OS X port, because it didn't work well enough. It made a real mess of Valgrind's scheduler, and it still had crashes and deadlocks because of bad interactions with the scheduler. Doing a gdb stub properly will require significant rethinking and replumbing of the scheduler. You'd need mechanisms for controlling the scheduler from inside the tool and/or error manager (stop now because an error occurred) and from the attached debugger (stop now because the user said so). Single-stepping and breakpoints are even more fun - you'd probably want a way to tell the scheduler to recompile only one instruction at a time, if that doesn't confuse the tools too much. -- Greg Parker gp...@ap... Runtime Wrangler |