From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15684 invoked by alias); 11 Dec 2009 23:59:09 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 15675 invoked by uid 22791); 11 Dec 2009 23:59:08 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Date: Fri, 11 Dec 2009 23:59:00 -0000 From: Daniel Jacobowitz To: archer@sourceware.org Subject: Re: Initial psymtab replacement results Message-ID: <20091211235901.GA16889@caradoc.them.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2009-q4/txt/msg00093.txt.bz2 On Fri, Dec 11, 2009 at 04:09:49PM -0700, Tom Tromey wrote: > I'm leaning toward ditching the .debug_gnu_index idea and simply going > with the standard sections instead. Let me know what you think of this. > > As far as I know the .debug_pub* approach is ok assuming (1) we take > Cary's suggestion of changing gcc to put everything in it, and (2) parse > the producer to see when the sections are usable. I want to get my comments on this into email, since IRC isn't a productive tool for this sort of discussion. This is pretty much the same as what I said on IRC yesterday. I still strongly support the idea of a debugger-specific cache, for the reasons below. There's prior art (according to Paul P.); we know this approach is practical. * It is simple to version and extend. If the cache is too old, either use what is there or ignore the cache. I believe that DWARF producer checks, while pragmatically necessary to work around some bugs, should be avoided whenever possible. And who knows what compiler versions end up with this backported to them. * It is still simple to preseed at distribution time. For instance, merge the cache generation process with whatever you use to generate separate debug info files, and put a cache there - with associated version, so that GDB knows what is and isn't in that cache. No need to maintain a local cache in $HOME if there's already one in /usr/lib/debug. * You've already had to make changes to GCC for this project. If you have to change GCC again, there's more users out there with even more backported and hacked up compilers that you have no idea whether pubtypes is complete enough. * Rolling out new compilers to people who want a new debugger may be easy for Fedora, but it just aint so in the rest of the world. We routinely get requests from customers who want to upgrade their debugger and continue to use the compiler they've validated for the past year. Changing the debugger is cheaper than changing the compiler, even if the work is already "out there" in trunk. * We also have customers using non-GCC compilers. You have users doing this too: icc, for instance. -- Daniel Jacobowitz CodeSourcery