From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) by sourceware.org (Postfix) with ESMTPS id D32BD3858D20 for ; Wed, 31 May 2023 23:44:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D32BD3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-qt1-x831.google.com with SMTP id d75a77b69052e-3f6c6320d4eso43251cf.1 for ; Wed, 31 May 2023 16:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1685576697; x=1688168697; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4bvIy9dkwSRSHHeR0RKbPJMk7RMmsVzCCdSuDB4cwUI=; b=FSfT5DnX24LcJlV+4l36yklQz+mU7oBrZ290+6Ea8twK8RJTLZsk7+NR9BWeI3ruzw yY4P4d4EhDoIe14bol2iD/N6UeFR7vOlGJHyM3UblBc8hw7z13vVXmIEja93ui2qLT+s 4MLYyTnZOgfN0zUDQjFodAjgrh7bso68G1oVAK1VEfAZTnWuAatKXi2uVx/UGew8r8Qg TK7OoL1x+s+nXJZ53R25TucLooRn5I9HodJzffOakq4xngbXDtIMcIFOvcr1JXu5ayud qzDO/KCcLRXHUwZGcBoPhcuBKL5g9ZlI6VhOeFkGnsRrANQNHRkJ8XFJ+ptombCV20C+ f8WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685576697; x=1688168697; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4bvIy9dkwSRSHHeR0RKbPJMk7RMmsVzCCdSuDB4cwUI=; b=dTPK0wNnA9hZO0FnlsIkDbhlkJbuIPjHQdXo502B8G/AxRztnnkJJdXJ9RfVGo/iaX 8ac7RyAmmQLrfetnGPI4bB+ZVBKhD7fXLTtauWcka6psIB+XoaoI/9mjw5yFp9xReyIr Aye5KzJ2YcTCOgdkLmd6uHv/gQ/tISRj4CRA1W5HRGjrj+luatwcfsxWikrZGCSn0khM uLX4wtsDyOtV75ByO3+zwQvtX+Sgo3st+uzwQI3afz8BOeWAGcwaRLzAOr0Fdva/EGO3 fHq1aeN70wTNaWVpC35ki3mnXr9UX8R9hWIzShCaCDQLneP12Sr1zX50SWXivg0bNSAT oXsg== X-Gm-Message-State: AC+VfDzxZk5o8/QQgvYt5DkMRGWO44TIE1IW3WRaHqzTEH+222BIpnX7 vpfz3WmY3c2WpQ+zY1HARMnXCJA+GxcywX3FhdrOlQspAB8naII276Q= X-Google-Smtp-Source: ACHHUZ52jGsnDa2hTMulf8rnoEMd5PAyuIugXYtyKJB5MN0AiR/sOFS46iAx6DQGbZQBVCqbrj/vxzHo8BQo1HihcB4= X-Received: by 2002:a05:622a:1a88:b0:3f7:ff4a:eae5 with SMTP id s8-20020a05622a1a8800b003f7ff4aeae5mr104789qtc.12.1685576696957; Wed, 31 May 2023 16:44:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roland McGrath Date: Wed, 31 May 2023 16:44:46 -0700 Message-ID: Subject: Re: Local Build ID Directory Lookup (DEBUGINFOD_LOCAL_PATH) To: Daniel Thornburgh Cc: elfutils-devel@sourceware.org Content-Type: multipart/alternative; boundary="00000000000043d55a05fd05e868" X-Spam-Status: No, score=-19.1 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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: --00000000000043d55a05fd05e868 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In elfutils, the libdwfl library is responsible for the "library for obtaining debug info writ large" stuff. It provides API parsers for command-line arguments that mesh with its library stuff like Dwfl_Callbacks that set the search path used equivalently to GDB's `set debug-file-directory` path. eu-* tools as well as things like systemtap use this to accept `--debuginfo-path=3DPATH`, but AFAIK none of them support environment variables. In the binutils world outside of GDB itself, I think only objdump and readelf do .build-id/... lookup and those use common binutils-private code (binutils/dwarf.c) that just has a hard-coded directory list. Some more uniformity here would be beneficial to everyone, I think. On Wed, May 31, 2023 at 3:17=E2=80=AFPM Daniel Thornburgh wrote: > Hi elfutils-devel@, > > I've been working on adding debuginfod support to various LLVM utilities, > while simultaneously setting up production use of debuginfod for a managed > developer environment. > > One issue that keeps cropping up is that there's often quite a few places > to get debug files from locally, in addition to various remote backends. > For example, the output of local build systems, prebuilt packages and > tarballs that a developer is working on, etc. > > One of the best things about debuginfod is that you can set up a service > once, then point an astonishingly wide array of tools at the server, with > one configuration. > > This isn't the case for files available locally, but there is some prior > art: GDB's build ID directory layout (commonly > `/usr/lib/debug/.build-id// ID>`). GDB has a flag to control this (`--with-separate-debug-dir`), but > that flag isn't shared by other tools. For example, binutils supports this > layout, but it simply hardcodes a list of directories to search for, with > no way to extend or override it. LLVM also supports this, but has a > differently named flag for it. > > Local files can be served to localhost using a debuginfod server, but this > incurs the overhead of transferring the files over a local socket on first > access, and the much worse overhead of storing an additional copy of the > file on disk in the debuginfod cache. With sufficiently large projects, > this gets pretty rough. > > It would be really nice if there were, a DEBUGINFOD_LOCAL_PATH environment > variable that provided a colon-separated list of directories in the GDB > `.build-id//` format to locally fetch files out of before > attempting remote servers. This would allow imbuing local build ID fetchi= ng > to tools that wouldn't otherwise support it, with one common configuration > language for how to do it. > > I did definitely want to raise this on the mailing list before starting to > implement something like this though, since it increases the scope of > libdebuginfod to include local fetching out of more than just out of its > own cache. It would stretch debuginfod towards a more general "library for > obtaining debug info writ large", rather than a straightforward remote > client library. > > Daniel Thornburgh | dthorn@google.com > > -- > You received this message because you are subscribed to the Google Groups > "(retired) tq-toolchain-team" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to tq-toolchain-team+unsubscribe@google.com. > To view this discussion on the web visit > https://groups.google.com/a/google.com/d/msgid/tq-toolchain-team/CAEdiOye= CSvpUijvZwJ%3DW2ncsGokefdm8z3yKVG%2Bu4jkAgXcumw%40mail.gmail.com > > . > > -- > You received this message because you are subscribed to the Google Groups > "rvos-toolchain-team" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rvos-toolchain-team+unsubscribe@google.com. > To view this discussion on the web visit > https://groups.google.com/a/google.com/d/msgid/rvos-toolchain-team/CAEdiO= yeCSvpUijvZwJ%3DW2ncsGokefdm8z3yKVG%2Bu4jkAgXcumw%40mail.gmail.com > > . > --00000000000043d55a05fd05e868--