[llvm] [Debuginfod] LLVM debuginfod server.

[noajshu]

Summary

This implements a debuginfod server in llvm using the DebuginfodCollection and DebuginfodServer classes. This is tested with lit tests against the debuginfod-find client.

The server scans 0 or more local directories for artifacts. It serves the debuginfod protocol over HTTP. Only the executable and debuginfo endpoints are supported (no /source endpoint).
The server also uses the debuginfod client as a fallback, so it can hit the local debuginfod cache or federate to other known debuginfod servers.
The client behavior is controllable through the standard environment variables (DEBUGINFOD_URLS, DEBUGINFOD_CACHE_PATH, DEBUGINFOD_TIMEOUT)

The server implements on-demand collection updates as follows:
If the build-id is not found by a local lookup, rescan immediately and look up the build-id again before returning 404. To protect against DoS attacks, do not rescan more frequently than once per N seconds (specified by -m).

Lit tests are provided which test the llvm-debuginfod-find client against the llvm-debuginfod server.

[phosek]

llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp

122

This should be controllable through a command line argument, elfutils' debuginfod supports -t SECONDS and defaults to 300 seconds.

[noajshu]

Add -c concurrency limit and -t scan interval command-line opts. Refactor almost all server logic out of llvm-debuginfod.cpp.

[noajshu]

Remove extra copy of the LLVM_ENABLE_HTTPLIB option

[noajshu]

Remove extraneous #includes from llvm-debuginfod.cpp and suppress unrelated cl options.

[noajshu]

Set llvm-debuginfod to use the hardware concurrency by default or if -c 0 is passed.

[noajshu]

Add end-to-end tests.

[noajshu]

rebase

[pcc]

llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp

11

Looks like this comment should be updated to describe llvm-debuginfod instead of llvm-debuginfod-find.

[pcc]

llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp

70

Could we make the bind interface configurable please? This will allow running a local symbol server without exposing it to other machines on the network.

[noajshu]

Incorporate DebuginfodLog. Fix tests by adding binary files and enabling concurrency. Make threading a requirement for the tests.

[noajshu]

llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp

70

Great idea, this has been added as the -i command line option.

[noajshu]

Add -v flag to enable verbose logging, suppress verbosity by default.

[noajshu]

Updated comments in llvm-debuginfod.cpp.

llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp

11

Thank you for catching this!

[phosek]

llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp

44

10000s is a long time between scans, elfutils defaults to 300s which I think would be better.

[pcc]

llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp

44

If the server implements the following behavior, do we need a scan interval?

• If the build-id is not found by a local lookup, rescan immediately and look up the build-id again before returning 404.

• To protect against DoS attacks, do not rescan more frequently than once per N seconds (e.g. N = 30).

debuginfod does not have this behavior and it was somewhat of a pain point when using it for local development.

[noajshu]

llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp

44

10000s is a long time between scans, elfutils defaults to 300s which I think would be better.

Thanks, will update this.

If the server implements the following behavior, do we need a scan interval?

Thanks for this suggestion, this would be really nice for local development. I've just updated D114845 (which implements DebuginfodCollection) to support this behavior via updateIfStale(), though we still need to add the option here. It's not much trouble to support both periodic and on-demand update triggers, so perhaps we could allow the when-to-update behavior to be customized by the cl::opts.

44

10000s is a long time between scans, elfutils defaults to 300s which I think would be better.

[mysterymath]

llvm/test/tools/llvm-debuginfod/llvm-debuginfod.test

25–27 ↗

(On Diff #426564)

It doesn't seem like the python script does anything for these two invocations; the DEBUGINFOD_CACHE_PATH is set manually, and there's nothing to wait for. It'd be clearer just to use llvm-debuginfod-find directly. This should also help remove conditional logic from the Python script.

51 ↗

(On Diff #426564)

Consider just env=os.environ, since env is otherwise unused.

54 ↗

(On Diff #426564)

58 ↗

(On Diff #426564)

llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp

44

It looks like this hasn't yet been updated as of the most recent patch.

98

Consider adding an llvm_unreachable() and a comment after this for documentation purposes; it was surprising to discover that the structure of the pool means it will never finish, but that there's still a wait call.

[noajshu]

Reduce default directory scan wait period to 300s, incorporate on-demand update using timer.

[mysterymath]

llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp

102

std::chrono::seconds? It looks like the implicit conversion should automatically convert the durations.

[noajshu]

Update the -t delay parameter to require integer delay time in seconds between scans.

[noajshu]

llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp

102

The goal of this was to allow someone to specify non-integer arguments, which would be rounded to the nearest millisecond. However I think it is more canonical to require an integer, so I've updated the argument and used your suggested conversion. Thanks!

[noajshu]

Rebase against main

[noajshu]

rebase against main

[fche2]

requesting lldb followup: https://github.com/llvm/llvm-project/issues/61547

[noajshu]

In D114846#4206434, @fche2 wrote:

requesting lldb followup: https://github.com/llvm/llvm-project/issues/61547

Hi @fche2 thanks for the ping.

D75750 is a great starting point that looked up source files with elfutils' debuginfod.

Integrating llvm-debuginfod into lldb may be pretty simple as the library comes for free with llvm if built with libcurl.

I am curious if others are already reviving this effort? I could work on it if not.

[mysterymath]

In D114846#4214141, @noajshu wrote:

In D114846#4206434, @fche2 wrote:

requesting lldb followup: https://github.com/llvm/llvm-project/issues/61547

Hi @fche2 thanks for the ping.

D75750 is a great starting point that looked up source files with elfutils' debuginfod.

Integrating llvm-debuginfod into lldb may be pretty simple as the library comes for free with llvm if built with libcurl.

I am curious if others are already reviving this effort? I could work on it if not.

I'm planning to pick this up in the vaguely nearish future (if noone else does), but I don't have a clear ETA for when I'll get around to it.

llvm/tools/llvm-debuginfod/CMakeLists.txt

+set(LLVM_LINK_COMPONENTS
+  Debuginfod
+  Support
+  )
+add_llvm_tool(llvm-debuginfod
+  llvm-debuginfod.cpp
+  )
+if(LLVM_INSTALL_BINUTILS_SYMLINKS)
+  add_llvm_tool_symlink(debuginfod llvm-debuginfod)
+endif()

llvm/tools/llvm-debuginfod/llvm-debuginfod.cpp

+//===-- llvm-debuginfod-find.cpp - Simple CLI for libdebuginfod-client ----===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+///
+/// \file
+/// This file contains the llvm-debuginfod-find tool. This tool
+/// queries the debuginfod servers in the DEBUGINFOD_URLS environment
+/// variable (delimited by space (" ")) for the executable,
+/// debuginfo, or specified source file of the binary matching the
+/// given build-id.
+///
+//===----------------------------------------------------------------------===//
+
+#include "llvm/Debuginfod/Debuginfod.h"
+#include "llvm/Debuginfod/HTTPClient.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/InitLLVM.h"
+#include "llvm/Support/ThreadPool.h"
+
+using namespace llvm;
+
+cl::OptionCategory DebuginfodCategory("llvm-debuginfod Options");
+
+static cl::list<std::string> ScanPaths(cl::Positional,
+                                       cl::desc("<Directories to scan>"),
+                                       cl::OneOrMore,
+                                       cl::cat(DebuginfodCategory));
+
+static cl::opt<unsigned>
+    Port("p", cl::init(0),
+         cl::desc("Port to listen on. Set to 0 to bind to any available port."),
+         cl::cat(DebuginfodCategory));
+
+static cl::opt<double>
+    ScanInterval("t", cl::init(10000),
+                 cl::desc("Number of seconds to wait between subsequent scans "
+                          "of the filesystem."),
+                 cl::cat(DebuginfodCategory));
+
+static cl::opt<size_t>
+    MaxConcurrency("c", cl::init(0),
+                   cl::desc("Maximum number of files to scan concurrently. If "
+                            "0, use the hardware concurrency."),
+                   cl::cat(DebuginfodCategory));
+
+ExitOnError ExitOnErr;
+
+int main(int argc, char **argv) {
+  InitLLVM X(argc, argv);
+  HTTPClient::initialize();
+  cl::HideUnrelatedOptions({&DebuginfodCategory});
+  cl::ParseCommandLineOptions(argc, argv);
+
+  SmallVector<StringRef, 1> Paths;
+  for (const std::string &Path : ScanPaths)
+    Paths.push_back(Path);
+
+  ThreadPool Pool(hardware_concurrency());
+  if (MaxConcurrency == 0)
+    MaxConcurrency = hardware_concurrency().compute_thread_count();
+
+  DebuginfodCollection Collection(Paths, Pool, MaxConcurrency);
+  DebuginfodServer Server(Collection);
+
+  if (!Port)
+    Port = ExitOnErr(Server.Server.bind());
+  else
+    ExitOnErr(Server.Server.bind(Port));
+  outs() << "Listening on port " << Port << "\n";
+  Pool.async([&]() { ExitOnErr(Server.Server.listen()); });
+  ExitOnErr(Collection.updateForever(
+      std::chrono::milliseconds(static_cast<int>(ScanInterval * 1000))));
+  Pool.wait();
+}