[Lldb-commits] [PATCH] D75750: [lldb] integrate debuginfod

Fri Apr 17 05:54:48 PDT 2020

kwk added a subscriber: fche.
kwk added a comment.

In D75750#1988330 <https://reviews.llvm.org/D75750#1988330>, @labath wrote:

> lldb-dev is indeed a better place for the architectural discussion. However, moving the discussion there does not automatically unblock this patch. "get something in now and improve the architecture later" almost never works out in practice. In fact I would say that adding debuginfod is a good way to cement the status quo.

I get that, but hear me out...

> The situation around finding symbols is messy enough already

The way in which I integrated debuginfod for now is just to find source files and not yet symbols. That being said. I don't fear the status quo so much. The status quo is probably worse for symbols than it is for source files, don't you think? So with *all* the CMake integration, the hosting inside `lldb/include/lldb/Host/DebugInfoD.h` and your beloved test case,

testcase <https://reviews.llvm.org/file/data/nmmuh7sjtwk33klf72lk/PHID-FILE-pycg2subdqjpm72liogl/meme-test_case>

I think it is fair to say that at least some work is there that can be taken into LLDB. **As long** as I fix the retrieval of the module in `SourceManager::File::CommonInitializer`. As suggested by @jankratochvil either here or on IRC, I would like to give it a shot and try to pass down the correct module to this function. I'd say, let's see if this function can be passed a Module and if the changes are worth it. The whole part for retrieving debug information can come when the architectural changes are done. But then it's a piece of cake to extend `lldb/include/lldb/Host/DebugInfoD.h` with the right methods to call the debuginfod client lib.

> because one needs to understand the funky mac symbol searching mechanism, which is pretty much impossible without a mac machine.

I'm setting up my old mac to compile LLDB and I guess @jankratochvil might soon also have his own Mac. This at least puts us in a position where we can verify some of our changes.

> After debuginfod, one will need to understand both, and have a linux machine with some debuginfod setup. The set of such people is likely to be empty of a long time...

I'm not sure if I understand you correctly but to me the *setup* is just to point to a machine with *your* or a hosted server. At least for OS binaries @fche2 @fche  (which is the correct one?) is making some effort to have those debuginfos and source files available and setup. That is a great start for most embedded systems with not much disk space to install all debug information I guess. Correct my if this is a wrong anticipation. Sure, I mean it will take a while before LLDB with debuginfod will make it into a distribution but hey, time flies by.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75750