From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16561 invoked by alias); 1 Aug 2006 00:42:51 -0000 Received: (qmail 16553 invoked by uid 22791); 1 Aug 2006 00:42:50 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 01 Aug 2006 00:42:47 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G7iLN-0006Wj-HU; Mon, 31 Jul 2006 20:42:45 -0400 Date: Tue, 01 Aug 2006 00:42:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Add expat to the GDB sources Message-ID: <20060801004245.GA24099@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <200607232318.k6NNIV28004376@elgar.sibelius.xs4all.nl> <20060724152438.GA17094@trixie.casa.cgf.cx> <20060724195118.GE13612@nevyn.them.org> <20060724214157.GC25632@trixie.casa.cgf.cx> <200607242229.k6OMTR1a022831@elgar.sibelius.xs4all.nl> <20060731173312.GA10875@nevyn.them.org> <20060731202422.GA16346@nevyn.them.org> <200607312132.k6VLWpMT002274@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607312132.k6VLWpMT002274@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00000.txt.bz2 Thanks for responding! On Mon, Jul 31, 2006 at 11:32:51PM +0200, Mark Kettenis wrote: > It all depends on what the external library is used for. Making > readline optional wouldn't make much sense, since it is used for GDB's > primary user interface. Making expat optional make much more sense to > me, as I can't see why I'd need it for a native debugger. I've tried to explain this a couple of times, but I've been a bit oblique about it. Here's a clearer attempt, I hope. The XML descriptions that I'm using for remote targets also encapsulate information that is useful natively. They could replace some chunks of C code in the gdbarch vector, like the bits which adjust NUM_REGS based on whether SSE/Altivec/FooExt are present, with simpler and more uniform mechanisms. And e.g. gdbarch_register_name would also be covered by the textual description. For you or me, that's not a particularly big deal. We know where all the bits go in existing ports. But this sort of thing makes it easier to retarget GDB for custom use, for people who are less familiar with GDB. That's not a business concern speaking, if you're wondering - purely FSF hat. It's not particularly in CodeSourcery's interest to make GDB easier to port for people not familiar with it, but I still think it's a Good Idea. I get the feeling from your "good of the few" comments that you're sometimes suspicious of our goals, which I think is really unfortunate. Whenever I'm working on the FSF gdb, rather than our various local branches, I try to keep the goals of the FSF gdb project in front of me. And I think the consistency would be really nice, too - delete a few of the internal interfaces and bundle them up into a clearer and better documented approach. And there's automated validation and such that you can do on data files that isn't possible on C (or is much harder). I used to think that most of the data-driven approach that I'm advocating here was basically worthless, but I've been forcibly exposed to modern software development a couple of times recently, and it really is a nicer way to work in a lot of ways. > That said, I'm willing to give in under two conditions: > > 1. We add the necessary glue to the toplevel configure such that it > accepts a --with-expat-dir option similar to the --with-gmp-dir > option that's already there for GCC. This will make it possible to > keep building everything in one tree, which would come close to > removing the objections I raised earlier about problemms installing > expat on systems I use to test GDB on. Did you know that the --with-gmp-dir option doesn't build anything automatically? It has to be already built before you can configure GCC; it does test -f in the specified directory and uses AC_TRY_LINK. Here's how you'd build them separately with the patch I posted: ../expat/configure --prefix=/home/me/gdb-install make make install ../gdb/configure --prefix=/home/me/gdb-install make # Will successfully find expat If that's what you'd like for expat also, I can implement it, but it's somewhat less useful than what I think you were describing. Unfortunately you can't take an expat tarball and drop it into the src tree and have it just build, which is another option. That requires a patch, since expat's makefiles do something fairly silly with CFLAGS that would be a GNU Coding Standards violation if it were a GNU project :-( > 2. Try to keep the bits that need expat "optional", and review whether > the code that needs it really benefits all of us, or only a few. I'll leave this at: I think that the bits we are submitting here are for the benefit of a bigger slice of GDB's users than you do. See Sascha's message on gdb@ this weekend for one example. And I hope it will eventually be useful for native users of GDB, at least by making it easier for us (the maintainers) to add support for new hardware features that they want to debug. The XML code has both architecture and target components. While the only target to implement it is remote.c, it's easy to keep it optional, and I'm willing. But I've already got patches which use this for the sim/ simulators and for native arm-linux debugging, and I have requests sitting in my queue to do similar things for two native PowerPC variants (74xx and e500; and at least the 74xx is a popular native architecture). -- Daniel Jacobowitz CodeSourcery