From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12839 invoked by alias); 3 Oct 2002 06:37:32 -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 12829 invoked from network); 3 Oct 2002 06:37:31 -0000 Received: from unknown (HELO jareth.dreamhost.com) (66.33.198.201) by sources.redhat.com with SMTP; 3 Oct 2002 06:37:31 -0000 Received: from hug.dreamhost.com (basic-cabo.hug.dreamhost.com [66.33.198.140]) by jareth.dreamhost.com (Postfix) with ESMTP id A8F986B609 for ; Wed, 2 Oct 2002 23:37:30 -0700 (PDT) Received: from paper-wolf-solo.tigerfood.org (localhost [127.0.0.1]) by hug.dreamhost.com (8.11.0/8.9.3/Debian 8.9.3-21) with ESMTP id g936bUf04392 for ; Wed, 2 Oct 2002 23:37:30 -0700 Received: from tigerfood.org (flee@localhost) by paper-wolf-solo.tigerfood.org (8.11.6/8.11.6) with ESMTP id g936aOi31950 for ; Wed, 2 Oct 2002 23:36:25 -0700 Message-Id: <200210030636.g936aOi31950@paper-wolf-solo.tigerfood.org> X-Authentication-Warning: paper-wolf-solo.tigerfood.org: flee owned process doing -bs From: Felix Lee To: gdb@sources.redhat.com Subject: remapping absolute source paths Date: Wed, 02 Oct 2002 23:37:00 -0000 X-SW-Source: 2002-10/txt/msg00029.txt.bz2 Say I have a program that has some absolute path names in the debugging info, like /a/x/foo.c but /a doesn't exist here. instead I have the source in /p. There's no easy way of making that work right in gdb, is there? If I say "dir /p", it's not going to look for /p/x/foo.c. If I say "dir /p/x" and for every other subdir in the tree, then gdb will have problems picking /p/x/foo.c from /p/y/foo.c I'm thinking either 1. there should be a way to tell gdb that "/a" in a source path should be remapped to "/p" 2. gdb should try every sub-path of the sourcefile name, so it should try /p/a/x/foo.c /p/x/foo.c etc. 1 is less transparent, but it's easier to control ambiguities, like if for some reason the executable has both /a/x/foo.c /b/y/foo.c which seems unlikely, but I could see it happening when linking several libraries and packages together. I'm leaning towards implementing 1. any thoughts? --