From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28960 invoked by alias); 4 Jan 2008 17:42:48 -0000 Received: (qmail 28949 invoked by uid 22791); 4 Jan 2008 17:42:48 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 04 Jan 2008 17:42:28 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id D1CDC98120; Fri, 4 Jan 2008 17:42:26 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id B35539801D; Fri, 4 Jan 2008 17:42:26 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JAqYr-0004Pg-Db; Fri, 04 Jan 2008 12:42:25 -0500 Date: Fri, 04 Jan 2008 17:42:00 -0000 From: Daniel Jacobowitz To: Aleksandar Ristovski Cc: gdb@sourceware.org, Ryan Mansfield Subject: Re: gdb_realpath: dealing with ./ and ../ Message-ID: <20080104174225.GA15473@caradoc.them.org> Mail-Followup-To: Aleksandar Ristovski , gdb@sourceware.org, Ryan Mansfield References: <2F6320727174C448A52CEB63D85D11F40A4A@nova.ott.qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F6320727174C448A52CEB63D85D11F40A4A@nova.ott.qnx.com> User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00021.txt.bz2 On Fri, Jan 04, 2008 at 11:38:44AM -0500, Aleksandar Ristovski wrote: > BUT... > This does not solve all my problems. In fact, when debugging on linux a > binary cross-compiled on windows, it won't work: > > IS_ABSOLUTE_PATH macro will differ depending on the configured gdb host. The > problem with this is when one is debugging binary cross-compiled on windows, > on a unix host, IS_ABSOLUTE_PATH will return 0 on "C:.." style paths which > is not correct. Looking at the code, in many places we concatenate directory > and file name if IS_ABSOLUTE_PATH returns zero so in case of cross-compiled > binary I suspect there will be many issues. Yes, this is something I've been meaning to fix for ages, but never had time. We need versions of IS_ABSOLUTE_PATH, FILENAME_CMP, and the other related macros which handle DOS pathnames regardless of the host system. We should give them different names, though, so that both are available (sometimes we need to manipulate host paths). > > > 2. Problem two - one physical file is specified with two pathnames. > > > > The specific case that's important here is associating the main file > > from a dwarf2 CU DIE with the right lines from .debug_line. When we > > go to create that subfile we haven't created the other subfiles yet. > > So what we need, I think, is to handle this in dwarf2read.c by walking > > through the filename / directory table. > > dwarf2read.c calls start_subfile or start_symtab which in turn calls > start_subfile. I think we should let our readers deal with "compiled" paths > (i.e. as found in the binary), without conversion. In start_subfile, > however, we can do something with paths. Currently, we do not try to > substitute-path on paths coming from the binary, even though they are > clearly our source paths and should be dealt with the same as with any other > source path. Substitute-path is designed to convert paths coming from the binary into paths for the host system. I don't understand why you're calling it this early; it doesn't matter if these files exist on the host system or not. I always have trouble understanding changes to this part of GDB. It would help a lot if you could write test cases. We can use gdb.dwarf2/ to construct arbitrary DWARF-2 contents, with relative or absolute paths as needed. If you have trouble writing the test cases, I can do it if you send me a couple of example binaries, and the before and after expected results. Or you might ask Joel or Eli to look at your patches. > Note2: for some reason, my post to gdb-patches didn't go through even after > two attempts. There I submitted only source.c change dealing with rewriting > source path in case when NAME is an absolute path and at the same time > DIRNAME is not NULL (which can happen). Please try using text for patches, instead of binary attachments. ChangeLog entries would be nice, too. -- Daniel Jacobowitz CodeSourcery