On Mon, Nov 08, 2004 at 09:19:25PM -0500, Andrew Cagney wrote:
Daniel Jacobowitz wrote:
On Mon, Nov 08, 2004 at 04:32:23PM -0500, Andrew Cagney wrote:
Given our already overcommitted backlog: breakpoints on C++
constructors, breakpoints on inline code, DW_OP_piece, i18n, multi-arch
solib, ....; how realistic is it that we'll, in addition, manage to both
refactor the linux code base (I know this will be slow as I've been
working on it) and also add multi-threaded watchpoints, all in the 6.4
time frame?
Let concentrate on clearing existing backlog, and not add another
promise to the list.
*sarcasm*
You're right. That's an excellent plan. Let's just drop the
multithreaded watchpoint patch, then, if it will never make it
to the front of the backlog.
*sarcasm off*
Looks like I touched a raw nerve, eh?
Well let me touch another one. Ask any serious developer trying to use
GDB and they'll tell you bluntly ``we sux'', and the things I listed
(along with multi-threaded watchpoints) are why ``we sux''.
Can we sux a lttle less and at least support multi-threaded watchpoints?
Yes, you touched a raw nerve. You touched a raw nerve where you are
attempting to hold contributions from different contributors to
different standards. For instance, you blocked vsyscall support for
months because you objected to the quality and design of the code; I
felt it was of satisfactory quality, but you and I already know that we
disagree about many aspects of software design.