From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17044 invoked by alias); 28 Mar 2006 22:17:52 -0000 Received: (qmail 17028 invoked by uid 22791); 28 Mar 2006 22:17:51 -0000 X-Spam-Check-By: sourceware.org Received: from sadr.equallogic.com (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 28 Mar 2006 22:17:50 +0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id k2SMHmxx011844 for ; Tue, 28 Mar 2006 17:17:48 -0500 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id k2SMHmfR011839 for ; Tue, 28 Mar 2006 17:17:48 -0500 Received: from pkoning.equallogic.com ([172.16.1.169]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Mar 2006 17:18:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17449.46602.392697.675583@gargle.gargle.HOWL> Date: Tue, 28 Mar 2006 22:57:00 -0000 From: Paul Koning To: gdb@sources.redhat.com Subject: Source directory trees not in build location 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/msg00191.txt.bz2 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