From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20589 invoked by alias); 3 Aug 2007 14:47:21 -0000 Received: (qmail 20580 invoked by uid 22791); 3 Aug 2007 14:47:20 -0000 X-Spam-Check-By: sourceware.org Received: from b.mail.sonic.net (HELO b.mail.sonic.net) (64.142.19.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 03 Aug 2007 14:47:15 +0000 Received: from snyder (209-204-172-156.dsl.dynamic.sonic.net [209.204.172.156]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with SMTP id l73ElAZ6032696; Fri, 3 Aug 2007 07:47:11 -0700 Message-ID: <001901c7d5dc$714de440$677ba8c0@sonic.net> Reply-To: "Michael Snyder" From: "Michael Snyder" To: "Daniel Jacobowitz" Cc: , "Mark Kettenis" References: <10431.12.7.175.2.1186103684.squirrel@webmail.sonic.net> <200708030554.l735scVD028947@brahms.sibelius.xs4all.nl> <000b01c7d59d$608d4040$677ba8c0@sonic.net> <10431.12.7.175.2.1186103684.squirrel@webmail.sonic.net> <20070803013005.GA22901@caradoc.them.org> <006901c7d587$db360400$677ba8c0@sonic.net> <20070803114033.GA16806@caradoc.them.org> Subject: Re: [PATCH] symfile.c, find_separate_debug_file Date: Fri, 03 Aug 2007 14:47:00 -0000 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 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: 2007-08/txt/msg00052.txt.bz2 > Adding "/" to strings is fine; it's when looking at passed in strings > that you have to check directory separators more carefully. > > On Fri, Aug 03, 2007 at 12:10:30AM -0700, Michael Snyder wrote: > > Well I don't know -- they seemed to hurt when I tried it, > > and getting rid of them certainly seemed to help. > > > > If I type /usr/lib//tmp/foo, isn't that equivalent, at least > > in some contexts, to typing /tmp/foo? > > To my knowledge this is true only in Emacs, not in any normal > operating system's file access routines. GDB does not run on top of > Emacs... > > Maybe you could describe how it seemed to hurt. Sure. It generates a string such as "/usr/local/lib/debug//opt/grbx/lib.so", which is then passed to the libc function 'open', which fails to find the file. When I remove the extra slash, open succeeds. This is glibc 2.5 running under UML in Scratchbox, on Ubuntu. Gdb is x86-cross-x86, not that that's probably relevant.