From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id BC4A6388206F for ; Fri, 14 Jun 2024 11:07:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BC4A6388206F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BC4A6388206F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718363222; cv=none; b=sRnxgpxd80todN77w8p3rZU8BAqhwKQdiREI7AsZ/YMjoKJFL7wvmnxWs0kV0+6oUz/WWbdCPVdhQ2Lwsfzlp4CPQ+DgKdXQ9angjeyT3/klc23OZ0HTa4R+NTZK0RnlQOWgJ+fW2Gcvjt6YAEJeARdyBgoBGOK0ediqdYElKPk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718363222; c=relaxed/simple; bh=1rcH1IMXQXQH2YNO7RYEU9lhBh0yLEw/QJuH6/wgFGY=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=SBYQ/H6cEB3beU1CDH7YvekEjcH5yS5st/GovIiPex9r2DoBDmDcOLD4Z8sj9PDStOGaa3ev4TEcXp/LmbIts65vLrRuDgIjdOFVEzBI0CG/lb+guDYhduHreZtP2wftQbUFL6X57O4LL9GWBp4wEZ9xThWldo1peU9w6NuXJfU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sI4ln-0008SC-OX; Fri, 14 Jun 2024 07:06:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+0aiUvePsHcv1BskpggmYqu8opdKnQGcjQ0jqIKnpX4=; b=dUf8SQnI/EeK arjnYBI9IVnSFZUm7uBT0BPAwcT3iSMPqdVpDgw1qRu/R+RZONPlDN/+UIP0agTUVohyv1Nf6VPOM vZK87McUL8TD98fIux6JF7ucqmUbI9ESWN212PGn6WfOpMbTyT47Ixjgkfl+FXWIynFaaLp2WUN9S f+EJf4lv3Nzw/ENidunJvwZaUKvD3VhHozzVIEiUVsbN41G1WT+JD6/BQWyRS+eMS+KHNRDimXJVg 5Qn+rNn8n7RjaUICHeUWIyDSktloIUexVz4BEUUOtkueEacaowLOU7hxM7NirkcA05OoUPEDIIF+4 XGRjF9DbvVM9UMe3k86GIw==; Date: Fri, 14 Jun 2024 14:06:56 +0300 Message-Id: <86o783ye9b.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: tom@tromey.com, gdb-patches@sourceware.org In-Reply-To: <87msnn99zy.fsf@redhat.com> (message from Andrew Burgess on Fri, 14 Jun 2024 09:58:09 +0100) Subject: Re: [PATCH 1/2] gdb: avoid '//' in filenames when searching for debuginfo References: <70fd0861b081eafbc89738a7e2582652d2d074fa.1718272366.git.aburgess@redhat.com> <87cyokeqoo.fsf@tromey.com> <87msnn99zy.fsf@redhat.com> X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > From: Andrew Burgess > Cc: gdb-patches@sourceware.org > Date: Fri, 14 Jun 2024 09:58:09 +0100 > > Tom Tromey writes: > > >>>>>> "Andrew" == Andrew Burgess writes: > > > > Andrew> The new combine_paths function is similar to the existing path_join > > Andrew> function (see gdbsupport/pathstuff.h), but unlike path_join the new > > Andrew> function doesn't require that the first path be absolute. > > > > From what I can see, path_join doesn't have this requirement. > > The docs say "The first element can be absolute or relative" and the > > code seems to agree. > > You're absolutely right. And I see what's happened. Somewhere along > the line the logic has gotten reversed in my head. The problem isn't > that the first _must_ be absolute with path_join, it's that everything > else _must_not_ be absolute, see these lines in path_join: > > if (i > 0) > gdb_assert (strlen (path) == 0 || !IS_ABSOLUTE_PATH (path)); > > And for what we're doing here we, for example, join the path to the file > (which is absolute) onto the debug directory, which might, or might not, > be absolute, e.g. these lines in find_separate_debug_file: > > /* If the file is in the sysroot, try using its base path in > the global debugfile directory. */ > debugfile = path_join (target_prefix_str, debugdir.get (), > base_path, debuglink); > > I've initially understood the problem, written the code, then come back > and added comments and a commit message, and gotten mixed up somewhere. > Sorry about that. > > Anyway, here's an updated patch. I've change one comment in symfile.c, > and I've also updated the commit message, other than that the patch is > unchanged. > > Oh, and just because I was doubting myself, I did try using path_join, > and as predicted the test (sysroot-debug-lookup.exp) causes GDB to > trigger an assertion as we are appending an absolute path. I suggest to test this with the first argument empty and the second starting with two slashes: those should be left intact, at least on MS-Windows (due to UNCs). Also, how do we make sure none of the arguments except the first one is an absolute file name? Or if we cannot ensure that, how do we handle the case where some non-first argument is an absolute file name? Btw, the GNU Coding Standards frown on using "path" for anything but PATH-style directory lists. The ones here should be called "file name" of "file_name" or "fname" or "file" or "directory", but not "path".