From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7CC1F387084B for ; Sat, 15 Jun 2024 15:28:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7CC1F387084B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7CC1F387084B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718465340; cv=none; b=T44tk97m14BRPHZ9NTdBZnVnfUuQhidvLelvSWZBcyNj5l1JBAW6HLaPjB+Gb1CbvVWkgcOQlltVccu5ovIxA0KZcbJaGcPDmRyYue/m3Oo0CfpSybcUJHKco6FKwQqXujTgRxVNy7NSZjiyelWEKO2Mo/Pj8N20LwI4vZqZY5A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718465340; c=relaxed/simple; bh=/SUC5FL6Hdse49XwgCkQqErks9Cu5d/cyEvOeMUpWrw=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=vHweu0vIuPmBbUkaIS+RUa+ky1DSg665C6+JLx5NE1s5uoBIuZIPcCiUkPp8V01lteJ1GCvsnNpn+UptMT1dg6Q3FIwpaKZV1LZXjTj6YtoBllnVA4PNYWKsG53v2VjPD8fpxUF+87+mPWE61gvd8DztM4GtW+WMh2cUVT9f6cI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1718465338; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7ss4+TGL6HQae++6RnmTJ5wpHSNIGsy7d+zz+kqdpR0=; b=dpwIEfEzP1JYq0Z+fTaMsz+izrZB3cdOzPnXrC4mePHilh91WbQnKpd5lkHuyxUoTNmMnV SQ9LdRkiKtj1EbFIUo3vFamqcd0m2n5OLVdtFsEUd63S/S4nkmdH9aWJQvI1djJDUHHROO l5YH5nQsiAUL1ttpuQbXDdz/JUKTsCM= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-584-EJWuXFdtMFKLWl4PZ2biyA-1; Sat, 15 Jun 2024 11:28:56 -0400 X-MC-Unique: EJWuXFdtMFKLWl4PZ2biyA-1 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-3608fb58acaso171470f8f.0 for ; Sat, 15 Jun 2024 08:28:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718465335; x=1719070135; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7ss4+TGL6HQae++6RnmTJ5wpHSNIGsy7d+zz+kqdpR0=; b=tCJn5+V/LchuMpHAXruH2RNCY8brv5ej5DkWd06GpgbJVa2iuT+9HiI3ZqYGR9+iHc u7/RzSFAMKB824degK2+u8FkhMKkytqSzWY5dZYgZe2LHmDLS95LNcw9u16K5p2bwXP4 JfTogK72kfso5BV3N9feP8TMUU6x9DZgYRl8JQ04ndRJ+5AXTSscGKnOpugjTdTj3+rl UGGQEHQMgUn1EMkdiG1g32LGlKhXWBBhC5yLCOfx3brRX51TNN25t+IvH8LvTdZ1FbXI ZdFsRJVmb5ugdn01lXEuo+ELaFwf0FSC8INdXsTPRVOc7RWToEHj2gMYIBussXpqpUYl vfaQ== X-Forwarded-Encrypted: i=1; AJvYcCX/NM/H9OtBdFjqWN9Q9/o/ysVcErWveYr7abLTzza7GizzZz0in78K97VqffIUjL3gOaTzHE415cKF6m43VxbgzICrQRrbokZJ8w== X-Gm-Message-State: AOJu0Yx5VnjnJMZCt7R8VE/qDVSduO76b6mhlHXt+JaMSGQjN/m71uj7 VpPoEOOGv/HSwikTmaxLtGlabuj41Rz7dKOTr23w1DmWY2MJ0GW8C6ckvaE7lym/YtWinDj1dJU oBpX5nme9dSdeevK6e5RiSZCUwVKk4cmESxLqsy2ezssljTxWf2P1x5A60RE= X-Received: by 2002:a5d:4009:0:b0:360:7c23:89e2 with SMTP id ffacd0b85a97d-3607c238a95mr4124160f8f.6.1718465335525; Sat, 15 Jun 2024 08:28:55 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFB91IIVxLd5qcQQZtFSfv5KYN5bj4euR6R5OoUlO5gO/MNU7s2o8jq21lYt26b7qioU2Sv/g== X-Received: by 2002:a5d:4009:0:b0:360:7c23:89e2 with SMTP id ffacd0b85a97d-3607c238a95mr4124150f8f.6.1718465335006; Sat, 15 Jun 2024 08:28:55 -0700 (PDT) Received: from localhost ([31.111.84.186]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-360750ad221sm7422787f8f.58.2024.06.15.08.28.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Jun 2024 08:28:54 -0700 (PDT) From: Andrew Burgess To: Eli Zaretskii Cc: tom@tromey.com, gdb-patches@sourceware.org Subject: Re: [PATCH 1/2] gdb: avoid '//' in filenames when searching for debuginfo In-Reply-To: <86plsitlwm.fsf@gnu.org> References: <70fd0861b081eafbc89738a7e2582652d2d074fa.1718272366.git.aburgess@redhat.com> <87cyokeqoo.fsf@tromey.com> <87msnn99zy.fsf@redhat.com> <86o783ye9b.fsf@gnu.org> <87ed8z8xfc.fsf@redhat.com> <867cery5dm.fsf@gnu.org> <87sexe7bci.fsf@redhat.com> <86plsitlwm.fsf@gnu.org> Date: Sat, 15 Jun 2024 16:28:53 +0100 Message-ID: <87h6du6x8q.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: Eli Zaretskii writes: >> From: Andrew Burgess >> Cc: tom@tromey.com, gdb-patches@sourceware.org >> Date: Sat, 15 Jun 2024 11:24:13 +0100 >> >> Eli Zaretskii writes: >> >> Our inputs: >> >> File we're debugging: d:/foo/bar/file >> Debug link name: file.debug >> DEBUG_SUBDIRECTORY: .debug >> debug-file-directory: x:/baz/quux/ >> sysroot: d:/foo/ >> >> Locations checked for debug, in this order: >> >> 1. d:/foo/bar/file.debug >> 2. d:/foo/bar/.debug/file.debug >> 3. x:/baz/quux/d/foo/bar/file.debug >> 4. x:/baz/quux/bar/file.debug >> 5. d:/foo/x:/baz/quux/bar/file.debug >> >> Of these, only (5) is obviously wrong I think as it didn't consider that >> the debug-file-directory might be an absolute path on a DOS based host. >> This code was introduced in commit: >> >> commit 402d2bfec425f29c5b54089d5ff98ca9a1b8ec27 >> Date: Tue Feb 12 13:56:16 2019 -0800 >> >> Look for separate debug files in debug directories under a sysroot. > > That should be fixed, IMO. And I'm willing to have a go, but that's a bug that exists before my patch, and is not made better or worse by my patch... it just happens to be in the same area, so hopefully it shouldn't block this patch moving forward? > >> As far as _this_ commit is concerned the _only_ change that might impact >> DOS based hosts is that, when joining absolute paths, I convert every >> instance of "//" within a path to "/". This only happens for paths >> after the fist one though, so if the first path starts with >> "//server/file" that will remain as it is. But if we try to do this: >> >> combine_paths ("//server_a/aaa", "//server_b/bbb") >> >> then we'd get: >> >> "//server_a/aaa/server_b/bbb" >> >> which might not be what we want. > > Given that we convert d:/ into d/ for the purposes of concatenation, I > think "//server_a/aaa/server_b/bbb" _is_ what we want. Awesome, so I think as far as this patch goes, there's nothing blocking it, right? I've attached below a patch which might fix the drive letter issue in the last case I described previously. Here's what I think you'll need to do to test this.... (1) compile a test binary. (2) split the debug into a separate file, e.g.: objcopy --only-keep-debug binary binary.debug objcopy --strip-debug binary binary.tmp mv binary.tmp binary (3) Add a debug link to the test binary, e.g.: objcopy --add-gnu-debuglink=binary.debug binary binary.tmp mv binary.tmp binary (4) Start GDB, but don't load the test binary yet. (5) Setup the sysroot to something containing a drive letter, e.g.: (gdb) set sysroot x:/sysroot/ (6) Setup the debug directory to something containing a drive letter, maybe a different drive letter? e.g.: (gdb) set debug-file-directory z:/debug/ (7) Place the test binary within the sysroot, e.g.: x:/sysroot/blah/binary (8) Place the debug information into a file: x:/sysroot/z/debug/blah/binary.debug (9) Tell GDB to load the test binary, and hopefully observe the debug symbols being loaded: (gdb) file x:/sysroot/blah/binary Even just typing that out this search strategy doesn't make much sense, I can't imagine this every being a use case that anyone would need. I suspect this makes more sense if the debug-file-directory is a relative path, with no drive letter, e.g. is "the location of debug within the sysroot", but the sysroot itself might change location between different machines maybe? If the above doesn't work (as I said, I'm writing this with no test machine availble) you can turn 'set debug separate-debug-file on', repeat step (9) and report the results, this will show where GDB is trying to access. Anyway, if this does work I'm happy to make it into a real patch and post it upstream. Thanks, Andrew --- diff --git a/gdb/symfile.c b/gdb/symfile.c index 2575c7f37c8..61daa65c765 100644 --- a/gdb/symfile.c +++ b/gdb/symfile.c @@ -1504,9 +1504,20 @@ find_separate_debug_file (const char *dir, else root = gdb_sysroot; + /* If DEBUGDIR has a drive letter then we're still going to + search within the sysroot, convert the drive to another + directory in the path. */ + const char *debugdir_str = debugdir.get (); + drive.clear (); + if (HAS_DRIVE_SPEC (debugdir.get ()) + { + drive = debugdir.get ()[0]; + debugdir_str = STRIP_DRIVE_SPEC (debugdir_str); + } + debugfile = combine_paths (target_prefix_str, root.c_str (), - debugdir.get (), base_path, - debuglink); + drive.c_str (), debugdir_str, + base_path, debuglink); if (separate_debug_file_exists (debugfile, crc32, objfile, warnings))