From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20661 invoked by alias); 13 May 2008 18:56:05 -0000 Received: (qmail 20648 invoked by uid 22791); 13 May 2008 18:56:04 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 13 May 2008 18:55:47 +0000 Received: from [10.42.100.129] (min.ott.qnx.com [10.42.100.129]) by nimbus.ott.qnx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J6QQX8AT; Tue, 13 May 2008 14:55:41 -0400 Message-ID: <4829E42D.4050105@qnx.com> Date: Tue, 13 May 2008 20:24:00 -0000 From: Aleksandar Ristovski User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: [RFC] new substitute path when loading feature References: <20080513181131.GA9899@caradoc.them.org> In-Reply-To: <20080513181131.GA9899@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00405.txt.bz2 Daniel Jacobowitz wrote: > On Tue, May 13, 2008 at 02:06:57PM -0400, Aleksandar Ristovski wrote: >> To properly translate the paths it is useful to be able to tell gdb >> to translate such paths into new environment. Existing >> "substitute-path" functionality seems like the most logical choice, >> and the diff exploits this to add new feature - rewriting source >> paths at readin time. > > Why is this feature useful? There shouldn't be anything that depends > on the paths being changed at readin time. > This is what prompted my change: (gdb) set substitute-path c:/Temp /tmp (gdb) symbol-file /tmp/dirs/debug/main2 Reading symbols from /tmp/dirs/debug/main2...done. (gdb) b main Breakpoint 1 at 0x8048418: file c:/Temp/dirs/main.c, line 3. (gdb) l 1 c:/Temp/dirs/main.c: No such file or directory. in c:/Temp/dirs/main.c (gdb) Now without my change, this will sometimes work, sometimes it won't. For example, if the program was compiled on windows like this: C:\Temp\dirs\debug>gcc -g -O0 -c ../main.c -o main.o things would work. However if built like this: C:\Temp\dirs\debug>gcc -g -O0 -c c:\Temp\dirs\main.c -o main.o things would not work (as shown above). My other motivation was that throughout the code we use IS_ABSOLUTE_PATH which simply doesn't work if gdb was not configured for that filesystem flavour (i.e. when configured for POSIX path it does not understand Win32 path naming). With rewriting paths at source, things work as expected. Further, in most cases when file lookup is done and binary contains alien path style (well, only when gdb is configured for POSIX but examinig win32 built binary) the path matches happen mostly by chance, i.e. by matching basename and not full path. This may (and probably will) cause problems every now and then when a binary contains two source files (whether CU or included file) with the same base name. In any case, it seems right to be able to rewrite paths at readin and let gdb "see" the binaries as if they were built locally. Thanks, Aleksandar