From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9679 invoked by alias); 17 May 2008 16:22:36 -0000 Received: (qmail 9670 invoked by uid 22791); 17 May 2008 16:22:36 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 17 May 2008 16:22:16 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JxPAj-0008Ho-8s for gdb-patches@sources.redhat.com; Sat, 17 May 2008 16:22:13 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 17 May 2008 16:22:13 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 17 May 2008 16:22:13 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [RFC] new substitute path when loading feature Date: Mon, 19 May 2008 04:12:00 -0000 Message-ID: References: <20080513190818.GA13776@caradoc.them.org> <4829E7DA.3010606@qnx.com> <20080513192041.GA14593@caradoc.them.org> <20080515160551.GA24101@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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/msg00538.txt.bz2 Vladimir Prus wrote: > Daniel Jacobowitz wrote: > >> On Tue, May 13, 2008 at 03:20:41PM -0400, Daniel Jacobowitz wrote: >>> On Tue, May 13, 2008 at 03:11:22PM -0400, Aleksandar Ristovski wrote: >>> > No, this particular issue is not because of the slashes, but rather >>> > due to IS_ABSOLUTE_PATH returning false on a path like "c:/Temp...". >>> >>> OK. I think I "fixed" FILENAME_CMP and not IS_ABSOLUTE_PATH, but it >>> would not be hard to do both. >>> >>> I'll try to post something tonight. >> >> Sorry, my existing patch was a mess so I had to rewrite it. I haven't >> really tested this; it doesn't break a native Linux GDB in any case >> that I consider significant. See the comments in defs.h and utils.c >> for the details. > > I probably miss somethings, but it looks like the uses of IS_ABSOLUTE_PATH > in symtab.c:lookup_symtab and symtab.c:lookup_partial_symtab should be changed to > GDB_IS_ABSOLUTE_PATH, too? > > Also, I see IS_ABSOLUTE_PATH been used in source.c:openp, inside the > "if (filename_opened)" block at the end, and your patch does not seem to change > that. Ok, the last one probably need not be changed, since we appear to always have host patch at this point. OTOH, I'm still unsure about symtab.c -- is calling lookup_symtab with the absolute path on the system where binary is compiled (not where gdb is run) something we want to support? In general, it seems that having IS_ABSOLUTE_PATH and GDB_IS_ABSOLUTE_PATH, and needing to use some reasoning where to use which one is too risky -- should we use GDB_IS_ABSOLUTE_PATH everywhere? - Volodya