From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25750 invoked by alias); 30 Sep 2003 16:53:18 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25743 invoked from network); 30 Sep 2003 16:53:17 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 30 Sep 2003 16:53:17 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1B06E2B89; Tue, 30 Sep 2003 12:53:17 -0400 (EDT) Message-ID: <3F79B4FD.8070805@redhat.com> Date: Tue, 30 Sep 2003 21:14:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy , pes@india.hp.com Cc: gdb@sources.redhat.com Subject: Re: Tracepoint support in Cygnus GDB ? References: <3F717475.33E13BC4@india.hp.com> <6654-Wed24Sep2003201904+0300-eliz@elta.co.il> <3F72FF8C.3080104@redhat.com> <6654-Sat27Sep2003132618+0300-eliz@elta.co.il> <3F75A491.4010203@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00393.txt.bz2 > The first step would be to start a discussion on this list and build > a consensus on how to do it. Michael and I would be happy to see > the tracepoint stuff worked on, so we'd help out as best we could. > If you convinced him you were serious, Andrew would probably explain > some of the things he hinted at in his previous message enough that > someone who doesn't actually share his cerebellum could start > working on them. Maybe he already has, and could post pointers to > archived messages. (Snide remarks aside) I would go through the archives and the target code (FIXME comments in remote.c, for instance) the the basic theory of the target stack has been posted and discussed many times. The key word "sandwich" in gdb@ throws up one such post :-) Just, please don't look to me for highly detailed and definitive interface specifications. I see no value in providing developers with such a level of formalization. Let the person writing the code figure out an interface that just meets the immediate need; and recognize that in 6 months new requirements will change the interface anyway. No need for immediate perfection. > - In the past, companies in positions of power have chosen to > implement various features in GDB as quickly and cheaply as > possible, and put off dealing with the impact on simplicity and > maintainability until never. I would say the original C++ and > thread support would fall in this category, but supporting (at one > point) forty-some architectures without much attention paid to the > interface between per-architecture and generic code had its effects, > too. The problem will always be there, and can't simply be attributed to employee pressure. As a reasonable generalization, people have a tendency to try to avoid the hard but necessary work of peer review, incremental design, shortcut avoidance, finishing features, writing testsuites, .... We're all responsible for ensuring these things do occure. enjoy, Andrew