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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
