[PATCH] D113717: [Symbolizer][Debuginfo] Add debuginfod client to llvm-symbolizer.

[Nico Weber via Phabricator via llvm-commits]

thakis added a comment.

@dblaikie, @phosek, @noajshu, @hans and I met (online) last month and talked about this for a bit.

The summary was the following action items:

- have Debuginfod have a callback and put http request in llvm-symbolizer, and make llvm-symbolizer instead of Debuginfod depend on libcurl (iirc @phosek offered to look at that)
- maybe have an llvm-symbolizer mode that doesn't do requests
- maybe have a way to explicitly request pre-downloads of debug info

----

Some notes about things mentioned during the meeting:

Concerts with the approach:

- separation of concerns is generally good; compiler shouldn't depend on network
- libcurl now makes it into the deps of llvm.so
    - some linux distros link it dynamically, so clang now depends on it transitively
  - consider llvm-symbolizer copied via adb to a device that has funky connectivity (easy to see this causing timeouts);
- bootstrapping
- parallelism, no write blocking if pre-read
  - would download in parallel atm

These concerns don't apply in all scenarios:

- .o storage might networked anyways, so less a concern there
- might have to pull stuff for dlopen()'d shared libraries
- would be happy if libllvm.so didn't depend on libcurl
- care about llvm-symbolizer and lldb
- current setup: build system image on one machine, strip binaries, upload debug info to GCS, then runs tests based on image, and then at runtime downloads debug info on demand
  - can't pull all debug info for all binaries, too much storage
- been using this model for 3 years now, seems to work fine
  - current thing not debuginfod based
- is opt-in based on env vars, so is that really different from having your debug info on a fuse mount
- (someone might add cmake var)


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

https://reviews.llvm.org/D113717