From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id TBqMH5qe62oxkxsAWB0awg (envelope-from ) for ; Wed, 04 Nov 2026 16:07:38 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=EOx1KWpm; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 679081E043; Wed, 04 Nov 2026 16:07:38 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id ECA891E043 for ; Wed, 04 Nov 2026 16:07:35 -0500 (EST) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 381F14BA2E1D for ; Wed, 4 Nov 2026 21:07:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 381F14BA2E1D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1793826454; bh=arJJUvK96fb5tQ5n+jgTX3yM1tmx4Xv8oWfMDBS6A0I=; h=Subject:To:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=EOx1KWpmNvqj/291w/G9GH/8f3/iGeS54JcJ2m67DzDglKWh/d2QYNL0DG0F4rsPs 5zOHjnv2sZi3NoTaGyHttq1ty6FMZILr7g1xLrQLIG8GSHKprojjmzy/Y55OX2MoZF MrL4/DBew8mo+KITBSOcu5zE+fGB0GRDqfuvr8xw= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 653D74BA2E2E for ; Wed, 4 Nov 2026 21:06:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 653D74BA2E2E ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 653D74BA2E2E ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1793826398; cv=none; b=AkXKbF/mpdAM2SdvxZ01WXERWZh25bCFpJ6zkW7JOQpPkvm3wYhcxIUErO+H5brLbwBnSJ0gnrmitpOkuyLlUDYeZf4ShCGNbl6TJt3OicRb/GWf2kD8QItMEaKCMY3Mt4sSkAjfyykKx6kC20Iaa/vI5OPwYf6THPCAYWcmtns= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1793826398; c=relaxed/simple; bh=IBIfKdinP2sK5/bKJwEHZNXMukIt1k+bn9IxkIqyIgA=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=KhWKVE1Kyt0wCRPaaPxrAXJxQ7R4gL7A9oIxynzCJIHjHl3/21EIMeCEBf6cmQFHxBXZii/nPQJAoPLDQ6KJs6v0jKSCtvM/yxiPEShf4RFhcehVoGCJYJsFT26vvZrWcjRHuR6rPkKs12sr+u+rlwdiprzTrJHQYRuNq0RW1lc= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=rhDYcSAX DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 653D74BA2E2E 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 1xOiBm-0002hP-9G for gdb@sourceware.org; Wed, 04 Nov 2026 16:06:36 -0500 Message-ID: Subject: debuginfod: why can't it save real filenames?? To: gdb@sourceware.org Date: Wed, 04 Nov 2026 16:06:33 -0500 Organization: GNU's Not UNIX! Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.62.1 (by Flathub.org) MIME-Version: 1.0 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Paul Smith via Gdb Reply-To: psmith@gnu.org Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" When I first started using debuginfod support in GDB I was delighted as it made things much simpler. But, the more I use it the more frustrated I am finding one specific aspect of it: there is no possible way (that I have discovered) to figure out what the actual library (or binary) name is, that I'm debugging with! It's quite infuriating. For example, if I run "info shared" I'm treated to an incomprehensible set of buildid-based pathnames from my cache, like: >From To Syms Shared Object Library 0x00007f 0x00007f Yes /home/me/.cache/debuginfod_client/c1ce8a211.../e= xecutable 0x00007f 0x00007f Yes /home/me/.cache/debuginfod_client/b86ba1ea9.../e= xecutable This is not useful. Even things like "info symbol xyz" show the buildid path rather than the library name. And if I run backtrace then the name of the library where the symbol appears is also this unintelligible value. Of course, I understand that the directory name is the build ID value and that it's how we ensure uniqueness so it's required, but why can't the static filename "executable" be changed to the name of the library or program that is being represented? Then it would be easy enough to understand. E.g, instead of: ~/.cache/debuginfod_client/1234567890.../executable couldn't we have: ~/.cache/debuginfod_client/1234567890.../libsyslookup.so ? Is this a limitation of the debuginfod client? Something GDB is doing? Or is there an option or facility to make this better that I haven't been able to find? Thanks for listening!