From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9643 invoked by alias); 12 Oct 2009 20:05:21 -0000 Received: (qmail 9620 invoked by uid 22791); 12 Oct 2009 20:05:19 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hel.is.scarlet.be (HELO hel.is.scarlet.be) (193.74.71.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Oct 2009 20:05:13 +0000 Received: from [172.17.1.10] (ip-81-11-245-41.dsl.scarlet.be [81.11.245.41]) by hel.is.scarlet.be (8.14.2/8.14.2) with ESMTP id n9CK4PfI011217; Mon, 12 Oct 2009 22:04:26 +0200 Subject: Re: shared lib dos filename style - one more question From: Danny Backx Reply-To: danny.backx@scarlet.be To: Joel Brobecker Cc: Daniel Jacobowitz , gdb-patches In-Reply-To: <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> <20091010021849.GC5272@adacore.com> Content-Type: text/plain Date: Mon, 12 Oct 2009 20:05:00 -0000 Message-Id: <1255378026.10921.251.camel@pavilion> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-DCC-scarlet.be-Metrics: hel 20001; Body=4 Fuz1=4 Fuz2=4 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/msg00246.txt.bz2 On Fri, 2009-10-09 at 19:18 -0700, Joel Brobecker wrote: > > 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. Yes this is the issue. > 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. I like this approach, it looks better than the current one. No refresh problem. You write as if the caller of solib_find should have the burden, but solib_find is not a static function so it may have more than one caller. (Except I can only find one : solib_bfd_open.) Should this be an issue ? Whether this is implemented in solib_find or solib_bfd_open is not a big difference. A simplistic loop around all the stuff currently in solib_find would probably do the trick : unixified = 0; do { .... all the lookups in_pathname = unixify (in_pathname); unixified++; } while (unixified < 2); When implemented in the caller (if that's a good idea), it obviously looks simpler, something like : found_pathname = solib_find (pathname, &found_file); if (found_pathname == NULL) found_pathname = solib_find (unixify (pathname), &found_file); if (found_pathname == NULL) perror_with_name (pathname); But then you'd have to be sure this remains the only caller, so it would be better to make solib_find a static function, and document this in the comment just above solib_find. As I said this is a better approach than the one I was using because : - it doesn't affect libiberty - it should automagically do the right thing - it doesn't have the drawback of requiring funky stuff (the part I didn't implement yet) when the user changes have_dos_based_file_system What should unixify() do ? 1. /path/to/a -> /path/to/a 2. \path/to/a -> /path/to/a 3. \path\to\a -> /path/to/a 4. c: -> . 5. c:\path\to\a -> /path/to/a Cases 4 and 5 will not happen in my use case (Windows CE / Windows Mobile / .. don't have drive letters), but it looks like a good idea to add this. Right ? Comments please ? > 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 :-). This looks simple enough. Implementing this is probably the same amount of work as doing "impact analysis" so I can do that quickly if it is considered worthwile. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info