On 13/12/2018 23:19, Zachary Turner wrote:
The permanent solution would be figuring out what to do about the
ObjectFile situation (e.g. do we want to make an ObjectFilePDB or do we
want to live in a world where SymbolFiles need not be backed by
ObjectFiles?), and then regardless of what we decide there, implementing
the SymbolVendor that can search a combination of locations including
(but not limited to) a symbol server. lldb already has the notion of a
symbol path. So using this we could just use that existing logic to
search the symbol path, and before you run LLDB make sure your minidump
.pdb files are in that search path. If we make an ObjectFilePDB, then
this should be able to fall out naturally of the existing design with no
additional work, because it will use the normal SymbolVendor search
logic. If we allow SymbolFilePDB to live without an ObjectFilePDB, then
we would have to make changes similar to what you proposed earlier where
we can still get a SymbolVendor and use it to execute its default search
algorithm, plus probably some other changes to make sure various other
things work correctly in the presence of ObjectFile-less SymbolFiles.
+1 for that.
I'm particularly interested in the result of this, as I'm in the middle
of adding ObjectFileBreakpad, whose raison d´être is to make things
interoperate more nicely with the rest of lldb.
My take on this is that going the ObjectFile route is going to be faster
and less intrusive, but it may produce some odd-looking APIs. E.g. maybe
the ObjectFilePDB will claim it contains no sections (which is the
traditional way of passing information from ObjectFiles to SymbolFiles),
but instead provide some private API to access the underlying llvm data
structures, which will be used by SymbolFilePDB to do it's thing.
OTOH, object-less symbol files has the potential to produce
nicer-looking APIs overall, but it will require a lot of changes to core
lldb to make it happen. E.g., besides the fact that searching for
"symbols" happens on the object file level (which is the whole reason
we're having this discussion), the object files are also responsible for
providing unwind information. That would have to change too.
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
