From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11067 invoked by alias); 29 Sep 2003 22:00:46 -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 11060 invoked from network); 29 Sep 2003 22:00:45 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 29 Sep 2003 22:00:45 -0000 Received: by zenia.home (Postfix, from userid 5433) id 2D6B620766; Mon, 29 Sep 2003 16:56:36 -0500 (EST) To: 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> From: Jim Blandy Date: Tue, 30 Sep 2003 05:43:00 -0000 In-Reply-To: <3F75A491.4010203@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-09/txt/msg00385.txt.bz2 Andrew Cagney writes: > > Right -- please contribute support for native tracepoints! > > The literal interpretation of this suggestion is to go away and not > come back until you've come up with an unmergable jumbo patch. Geez. It's not as if I said, "--- and please do it badly!!!" Saravanan, I think there are two points germane to your original post: - At the moment, I don't know of any company that is investing effort in the tracepoint support. But GDB's feature set is not restricted to those things that a small group of corporations decide they want in closed meetings. Anyone with the skills and the patience to work through the design with the rest of the group, and the time to code it up, can get a feature in. So if native support for tracepoints is of interest to you, and you think you've got the skills and the time, I really encourage you to take it on yourself. 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. - 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. Andrew's spent years doing work on GDB's fundamentals to disentangle the architecture description system and the frame system. I just re-did one architecture's frame handling using his new interfaces, and it took me a single day to finish. This used to take me a week, and it'd still be wrong. David Carlton essentially volunteered a year of his time to work with Daniel Jacobowitz to straighten out the C++ support. I'm not a C++ user myself, but I understand it's vastly better than it used to be. In this context, you can see why one would want to place an emphasis on cleaning up some of the supporting infrastructure to make way for native tracepoints, and then doing it right, rather than just pursuing the shortest path.