From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30498 invoked by alias); 28 Mar 2006 22:57:36 -0000 Received: (qmail 30488 invoked by uid 22791); 28 Mar 2006 22:57:35 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao04.cox.net (HELO eastrmmtao04.cox.net) (68.230.240.35) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 28 Mar 2006 22:57:34 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao04.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060328225729.FMQL19943.eastrmmtao04.cox.net@localhost.localdomain>; Tue, 28 Mar 2006 17:57:29 -0500 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FON81-0004QC-Lq; Tue, 28 Mar 2006 17:57:33 -0500 Date: Tue, 28 Mar 2006 23:57:00 -0000 From: Bob Rossi To: Paul Koning Cc: gdb@sources.redhat.com Subject: Re: Source directory trees not in build location Message-ID: <20060328225733.GF9767@brasko.net> Mail-Followup-To: Paul Koning , gdb@sources.redhat.com References: <17449.46602.392697.675583@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17449.46602.392697.675583@gargle.gargle.HOWL> User-Agent: Mutt/1.5.9i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00193.txt.bz2 On Tue, Mar 28, 2006 at 05:17:46PM -0500, Paul Koning wrote: > We have a large source tree with many directories. When the system is > built that tree appears in one place in the namespace; then the build > results are saved in "good builds" directories, one per good build up > to whatever we can save. > > The result is that source files are not where they were at build time. > > GDB can handle this on a per-directory basis with the "directory" > command, but when you have on the order of a hundred directories that > is excessively painful. > > I made a local patch to add a source path name rewriting rule. That > allows a substring of the source path name to be replaced by some > different substring. The current implementation is simplistic -- it > allows exactly one substitution rule, and the matching is exact string > match. It would be possible to allow multiple rules, and probably > also fancier mechanisms like regexps. That wasn't necessary for our > application. > > Is this of interest to the greater GDB? > > paul > Well, I'm not sure if that's necessary. Has anyone gone back to this patch http://sourceware.org/ml/gdb-patches/2005-10/msg00092.html? Although, your solution seems really nice too. Bob Rossi