From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3296 invoked by alias); 28 Sep 2003 22:23:56 -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 3287 invoked from network); 28 Sep 2003 22:23:55 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 28 Sep 2003 22:23:55 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 686E02B89; Sun, 28 Sep 2003 18:23:40 -0400 (EDT) Message-ID: <3F775F6C.8070209@redhat.com> Date: Sun, 28 Sep 2003 22:25: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: Eli Zaretskii 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> <1659-Sat27Sep2003204134+0300-eliz@elta.co.il> <3F75D8D3.2090207@redhat.com> <2427-Sun28Sep2003102631+0300-eliz@elta.co.il> <3F76EC92.6010005@redhat.com> <4098-Sun28Sep2003234119+0300-eliz@elta.co.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00352.txt.bz2 >> Date: Sun, 28 Sep 2003 10:13:38 -0400 >> From: Andrew Cagney >> >> Keep in mind that GNU systems are a priority. > > > I'm aware of that, but IMHO GDB development favors GNU/Linux too much. > And since the Linux kernel changes so frequently, the symbiotic > relationship between GDB and GNU/Linux tends to consume a lot of > resources, as we are shooting a moving target. There's a certain irony here. People also complain that GDB favours embedded systems over GNU/Linux native systems; and spends too much time adding new architectures. The symbiotic relationship is between GDB and the compiler; not GNU/Linux. It's the compiler that GDB's trying to keep pace with (well actually catch up). As for GNU systems (such as GNU/Linux). If existing functionality breaks, we'd better do something about it. TLS, for instance, is an ABI extension that is implemented by GCC (with a little bit of co-operation from the [linux] kernel and [g]libc). Non GNU/Linux systems will definitly pick up and exploit the feature! >> TLS and NPTL are native GNU/Linux only for reasons out side of GDB's >> control. Tweaking TLS for other systems should be straight forward. >> >> Follow fork isn't GNU/Linux specific (it originated in HP/UX) but does >> need per-native target changes. > > > The facts are that these features are currently available only for > GNU/Linux. This simply reflects the reality that most developers use GNU/Linux systems. Unlike the past, the emphasis is on doing the internals in a portable way so that they do apply across all systems. This definitly wasn't the case when the original HP/UX only follow-fork implementation was committed. The missing bit is an interest, by non GNU/Linux users, in getting the features added to their system. >> Separate debug info is very much an embedded feature - it lets embedded >> distros make optional all the debug info for all those embedded C and >> C++ libraries. > > > Still, it requires a feature in Binutils that only exists on > GNU/Linux. Eli, here you're simply wrong. It requires a compatible toolchain (binutils, elfutils). It does not require GNU/Linux. > Are you saying that there's no way we could set up practical goals for > GDB development? I'd be surprised if you actually meant that, but > that's how it sounds. I'm saying trying to tie specific features to specific releases is unrealistic. >> Having largely disconnected the release schedule from features, we're >> doing much better. We make regular GDB updates that do contain new >> features and, more importantly, fixes. > > > As I said at the beginning of this discussion, I'm worried by the fact > that most of the recent GDB development effort is consumed by fixing > bugs and by building infrastructure, and very little goes into > user-level features. So I applaud the progress being made in the > directions you describe, but I'd like to see our progress defined more > by user-level features, not only by bugfixes and infrastructure-related > work. >> > IMHO, having a relatively short list of user-level features that are >> > first priority would be a good aid for maintainers, in setting their >> > priority to review patches, if for nothing else. > >> >> I believe everyone here knows the #1 priority. Make: >> >> (gdb) break main >> (gdb) run >> (gdb) bt >> (gdb) print foo >> >> work. At present it doesn't. > > > Something that should work but doesn't is a bug. So you again are > talking about fixing a bug; I don't see any user-level feature in the > above. The above is subtle. Having it work correctly requires the constant addition of new features. >> Breaking it down, "print foo" and "break >> main" both require name spaces, "bt" requires improved frame code. > > > That's infrastructure again. While I understand the need for building > good infrastructure, I hope that infrastructure will be used for > adding user-level features, hopefully sooner rather than later. Is the request to support debugging i386 binaries on x86-64 a bug, infrastructure, or a user visible feature? I'd argue its a feature, only, once working it just gives the user a better "break main; run" experience. Is namespace support a bug, infrastructure, or a new feature. Again, I'd argue that its a new feature, but again at the end of the day it just improves "break main; run". Is the lack of lazy breakpoints a bug, infrastructure or new feature (it's what every Java developer I know is asking for)? In the end, though, it too only results in a better "break main; run" experience so I guess its a bug. The inability to set a breakpoint on inline functions? Bug? Infrastructure? Feature? Anyone using anything inline complains about that one. I can't think of anyone here that is working on infrastructure for infrastructures sake (If I were doing that I'd be spending my time re-writing architecture specific code instead of deprecating / deleting them :-). The objective is new features. However, due to past neglect, we're now paying dearly spending more on cleanup and [arrrrg] finish up and less on user features. Andrew