From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21753 invoked by alias); 3 Mar 2004 17:54:40 -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 21726 invoked from network); 3 Mar 2004 17:54:39 -0000 Received: from unknown (HELO thoth.sbs.de) (192.35.17.2) by sources.redhat.com with SMTP; 3 Mar 2004 17:54:39 -0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i23Hsc428200 for ; Wed, 3 Mar 2004 18:54:38 +0100 (MET) Received: from burundai.radix50.net (mhpa1brc.mchp.siemens.de [139.23.185.77]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i23Hsbi22971 for ; Wed, 3 Mar 2004 18:54:38 +0100 (MET) Received: from burundai.radix50.net (localhost [127.0.0.1]) by burundai.radix50.net (8.12.3/8.12.3/Debian -4) with ESMTP id i23HspE2005299 for ; Wed, 3 Mar 2004 18:54:51 +0100 Received: (from ibr@localhost) by burundai.radix50.net (8.12.3/8.12.3/Debian -4) id i23HspDk005297 for gdb@sources.redhat.com; Wed, 3 Mar 2004 18:54:51 +0100 Date: Wed, 03 Mar 2004 17:54:00 -0000 From: Baurjan Ismagulov To: gdb@sources.redhat.com Subject: Re: handling of absolute source file paths (feature wish/implementation idea) Message-ID: <20040303175451.GC4677@ata.cs.hun.edu.tr> Mail-Followup-To: gdb@sources.redhat.com References: <200401221601.17594.gernot.hillier@siemens.com> <1659-Thu22Jan2004192206+0200-eliz@elta.co.il> <20040122175828.GA18705@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040122175828.GA18705@nevyn.them.org> User-Agent: Mutt/1.5.4i X-SW-Source: 2004-03/txt/msg00026.txt.bz2 Hello, Daniel! On Thu, Jan 22, 2004 at 12:58:28PM -0500, Daniel Jacobowitz wrote: > > > 3. Implement a new setting "source-absolute-prefix" (analog to the already > > > existing "solib-absolute-prefix") which allows the user to set a prefix for > > > given absolute source code paths. ... > src/include/elf.h > src/bfd/elfarm-nabi.c > src/bfd/elf32-arm.h > obj/bfd/bfd.h > > obj/bfd/elfarm-nabi.o: > compilation dir /blah/obj/bfd > path to source ../../src/bfd/elfarm-nabi.c > include flags -I. -I../../src/bfd -I../../src/include > > I want to be able to issue one command and find elf32-arm.h, > elfarm-nabi.c, bfd.h, and elf.h. They all have relative paths, rooted > at compilation directory /blah/obj/bfd. It happens to have been moved > to /blah-backup/obj/bfd and /blah-backup/src/bfd. I can't see how source-absolute-prefix could help. If you set it to /blah-backup, gdb would look for /blah-backup/../../src/bfd/elfarm-nabi.c and wouldn't be able to find it. If you set it to /blah-backup/obj/bfd and ask for ../../../src/gdb/cli/cli-cmds.c (compiled under /blah/obj/gdb/cli), gdb would again not find it. How did you want to use it? I think the problem is actually the fact that we use gdb/source.c:openp() both for binaries and sources. For the former we don't want to search the path if the name contains directory separators due to the reasons discussed before in this thread. For the latter we currently do the same; is it just because it is handled by the same function, or are there any other reasons? Seems that if we look for source files (both absolute and relative) in the supplied path, we can use dir command to access the source trees that were moved -- and this is, according to gdb 5.3 info documentation, what dir command was intended for. As far as I could see, 1) implementing source-absolute-prefix would also require this rearrangement, 2) the case with trees moved deeper in hierarchy is the only problem solved by source-absolute-prefix, and 3) it would be already covered by dir if we process binaries and sources differently. That is why I suggest that I modify openp so that it looks into search path for source files (I'm thinking about replacing try_cwd_first with a set of boolean flags determining the various aspects of the algorithm and adding the respective flag for searching). What do you think? With kind regards, Baurjan.