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?


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

https://reviews.llvm.org/D55434



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to