[PATCH] D114845: [llvm] [Debuginfod] DebuginfodCollection and DebuginfodServer for tracking local debuginfo.

Daniel Thornburgh via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 27 16:26:15 PDT 2022


mysterymath added a comment.

In D114845#3487357 <https://reviews.llvm.org/D114845#3487357>, @noajshu wrote:

> First, I wonder if it wouldn't hurt to add a `/source` endpoint, which doesn't check the local `DebuginfodCollection` at all but simply skips straight to using the client.
> This way, users who run a local debuginfod server would only have to set all their known public servers in the `DEBUGINFOD_URLS` variable once when they start `llvm-debuginfod`. When they use a client tool (like `llvm-symbolizer`) it would suffice to point to their local server only, as all requests would be federated.

Seems to me like we'd eventually want the source endpoint to behave like the other endpoints: first try looking things up locally, then federate. Both behaviors would be naturally supported when we get around to implementing the source endpoint. The behavior you describe would be the one you'd get if you provide an empty list of paths to scan.

> Second, I was wondering if there is any desire to split this out into two or more diffs. For example, although the changes to ThreadPool and Symbolize are quite small I'm happy to separate them out if desired.

IMO, the symbolize change seems safe enough, but ThreadPool is a pretty foundational library. It seems wise to separate this out and loop in the folks who've tended to touch the thread pool; they may have more specific opinions.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114845/new/

https://reviews.llvm.org/D114845



More information about the llvm-commits mailing list