[Lldb-commits] [PATCH] D55434: ObjectFileBreakpad: Implement sections

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Dec 7 10:29:19 PST 2018

labath added a comment.

I guess I should elaborate more on the direction where I am going with this. I am trying to model these breakpad files as a debug-info-only object file, like something you would get by running say `strip --only-keep-debug`. This object file will contain a bunch of sections, but none of them will be real loadable sections. They will basically just be containers for data (DWARF, most likely). Like the `.debug_***` sections, my sections also have vm_size set to 0, so there no notion of them being in memory or being slid around. The idea is that this file will never be used as the **main** object file for a module (*), but rather an object file that a symbol vendor uses to add symbol information to the module.

I have a follow-up patch to this (not yet ready for upload), where I create a SymbolFileBreakpad, which takes the "PUBLIC" and "FUNC" sections and uses them to add symbols into the symtab of the main object file using the interface we added for SymbolFilePDB (while doing that, I lookup these addresses in the main object file and resolve them to real sections (.text, etc.).  Then, another part of that plugin would take the line information from the "FUNC" section, and convert that into a `lldb_private::LineTable` structure. So, basically the real action will happen in the SymbolFile plugin, and this ObjectFile is there just as a fancy container for the data.

(*) I am deliberately not handling the scenario where we have the main ObjectFile missing. We need to be able to handle the case when we cannot find the main object file regardless of whether we have the breakpad file around or not (and ProcessMinidump kind of does that right now, but I believe that should be generalized), so I am planning to have breakpad  just piggy-back on that. Then if we have a real object file, we can get accurate section information from there. If not, then all of our symbols will resolve to some fake section encompassing the whole module.

Does this approach make sense?



More information about the lldb-commits mailing list