From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4027 invoked by alias); 10 Oct 2009 02:19:02 -0000 Received: (qmail 4011 invoked by uid 22791); 10 Oct 2009 02:19:01 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 10 Oct 2009 02:18:54 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 16A6D2BAC84; Fri, 9 Oct 2009 22:18:53 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MzpNKev0fjpN; Fri, 9 Oct 2009 22:18:53 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9F12D2BAB98; Fri, 9 Oct 2009 22:18:52 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 22060F589F; Fri, 9 Oct 2009 19:18:49 -0700 (PDT) Date: Sat, 10 Oct 2009 02:19:00 -0000 From: Joel Brobecker To: Danny Backx Cc: Daniel Jacobowitz , gdb-patches Subject: Re: shared lib dos filename style - one more question Message-ID: <20091010021849.GC5272@adacore.com> References: <1253973110.10921.76.camel@pavilion> <1254946075.10921.178.camel@pavilion> <20091007201145.GA21557@caradoc.them.org> <1255017831.10921.197.camel@pavilion> <20091009173650.GB5272@adacore.com> <1255114781.10921.217.camel@pavilion> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1255114781.10921.217.camel@pavilion> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2009-10/txt/msg00198.txt.bz2 > Gdb talks to the remote process to debug via gdbserver. This all works > very well until you want to interact with DLLs. In some circumstances > (e.g. with Windows Embedded CE on x86), gdb will receive DLL information > with full paths to the DLLS. If I understand the actual technical issue, it's that GDB fails to compute the basename of our DLL when trying to locate it through the solib search path. Is that correct? So you're trying to tell GDB to use the dos FS conventions so that, when getting the basename of your DLL, it properly computes the basename and allows the search to succeed. My thoughts on that are similar to Daniel's: I don't think that we'll see many files on UNIX systems that start with d: or d:\, nor will we see a lot of backslashes either. But you never know, people like to shoot themselves in the foot, I've noticed. I would agree to changing GDB so that pathnames are treated as DOS pathnames, modulo the case-sensitivity issue. This means that d:/ or d:\ is treated as a drive, and that forward and backward slashes are treated as directory separators. I don't think we want to start treating filenames as case-insensitive on Unix systems. But I think that this should still remain under control of a setting that allows GDB to revert to using the host filesystem convention. That way, if we run into unexpected issues, we can tell a user how to get back to the previous behavior. Another venue that I don't think we have explored, is to fix the problem locally in solib:solib_find. Have we considered enhancing it in a way that, if solib_find found nothing, then call it again, but with a Unix-ified path. If the file happens to be the in solib search path, it should be able to locate and return it. The latter is interesting, because at the heart of the problem is the fact that GDB no longer knows whether it's dealing with a host filename or a remote filename. It doesn't matter in the case where we are debugging natively. But it starts mattering when we are debugging remotely: This is when translations start becoming required... So far, we've been able to accomodate most/all situations encountered in practice by little tricks such as substitute-path and solib-search-patch. Anyway, these are only my 2 cents. Others may have different opinions, and I suggest we reach a consensus before you go off and implement anything. I suggest you pick one solution that you like and ask if anyone has any problem with it :-). -- Joel