From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30594 invoked by alias); 22 Jan 2004 15:01:38 -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 30515 invoked from network); 22 Jan 2004 15:01:35 -0000 Received: from unknown (HELO goliath.siemens.de) (192.35.17.28) by sources.redhat.com with SMTP; 22 Jan 2004 15:01:35 -0000 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i0MF1X006158 for ; Thu, 22 Jan 2004 16:01:33 +0100 (MET) Received: from m20228pp.mchp.siemens.de (m20228pp.mchp.siemens.de [139.23.187.120]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i0MF1Xl26112 for ; Thu, 22 Jan 2004 16:01:33 +0100 (MET) From: Gernot Hillier Organization: Siemens AG To: gdb@sources.redhat.com Subject: handling of absolute source file paths (feature wish/implementation idea) Date: Thu, 22 Jan 2004 15:01:00 -0000 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200401221601.17594.gernot.hillier@siemens.com> X-SW-Source: 2004-01/txt/msg00243.txt.bz2 Hi! We use gdb for host/target debugging. As some of our targets are rather big= in=20 respect to memory/disk space/..., we prefer to use gdb via remote login on= =20 the target instead of using gdbserver/gdb often. Therefore, we mount the sources from the development hosts on the target. T= his=20 means in our environment that a source file, available on the host as /a/b/ c.cpp gets mounted on /mnt/a/b/c.cpp on the target. Unfortunately, our make environment uses absolute paths when building our=20 projects. Everything worked very nice with gdb 5.3 for us by logging on to the target= ,=20 changing to /mnt and starting gdb. gdb searched absolute source code paths= =20 not only absolute, but also relative to all given paths.=20 But since we switched to gdb 6.0, the target gdb isn't able to find the sou= rce=20 files any more because absolute paths are only searched starting from /. We identified the reason in this change of gdb/source.c: Revision 1.39, Mon Jan 13 20:11:47 2003 UTC by drow * source.c (openp): If the file does not exist don't necessarily search the path. (see http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/ source.c.diff?r1=3D1.38&r2=3D1.39&cvsroot=3Dsrc for the patch) Now we solved the problem for us by reverting this change but we would very= =20 much like to remove this hack and see it solved cleanly in the mainline.=20 We would be happy to implement a patch and send it to you for inclusion, bu= t I=20 wanted to hear what you think about our ideas before doing it. I see three ways of resolving this issue currently: 1. Reverting the change in the mainline as we did. I currently can see no r= eal=20 reason why this change was made but I think there was a reason. So I assume= =20 you won't like it, do you? 2. Implement a new setting "source-absolute-search-mode" which - when enabl= ed=20 switches back to the old behaviour and tries to find absolute paths=20 nevertheless also relative to all given paths. 3. Implement a new setting "source-absolute-prefix" (analog to the already= =20 existing "solib-absolute-prefix") which allows the user to set a prefix for= =20 given absolute source code paths. So what do you think about these ideas? Any other suggestions (besides that= we=20 should change our make environment which is unfortunately not too easy)? Many thanks in advance for your constructive feedback... --=20 Bye, Gernot Hillier CT SE 2 Siemens AG, Mch P