[Lldb-commits] [PATCH] D55142: Minidump debugging using the native PDB reader

Greg Clayton via lldb-commits lldb-commits at lists.llvm.org
Tue Dec 11 09:50:12 PST 2018



> On Dec 11, 2018, at 7:14 AM, Pavel Labath <pavel at labath.sk> wrote:
> 
> On 11/12/2018 01:08, Greg Clayton wrote:
>>> On Dec 10, 2018, at 3:11 PM, Leonard Mosescu <mosescu at google.com <mailto:mosescu at google.com>> wrote:
>>> 
>>> I can see how this works for the PDB, no-module-binary case. What about the PDB & module-binary case?
>> That would work fine because the symbol vendor will make an object file from the m_symfile_spec and use both the original binary + the symbol file to make symbols.
>>> Maybe I missed the rationale, but I think that modeling the general case: module and symbols are separate files, is a better foundation for the particular case where the symbols are embedded in the binary file.
>> Yeah, my case should handle the following cases:
>> - Minidumps Placeholder modules only, no real binaries, add symbols by downloading them and using "target symbols add ..."
>> - Download real binaries up front and load them into LLDB, then load the core file. For any binaries we do have, we should grab them from the global module cache (GetTarget().GetSharedModule(...) in the current code) and they will use real object files, not placeholder files. "target symbols add ..." still works in this case
> 
> It sounds to me like it would be better to have a separate command (let's call it "target modules replace" for now) for adding an "object file" to a "placeholder" module, instead of repurposing "target symbols add" to do that.
> 
> This creates a strange loop between the symbol and object files -- normally we use the object file for symbol representation if the user hasn't specified a symbol file, and here, we would do the opposite.
> 
> With "target modules replace", one command would still be enough to set both the symbol and object files if they are the same, as the default use-symbols-from-object-file behavior would kick in. However, it would leave the "target symbols add" command free to add symbols from an external file.
> 
> Imagine the following scenario:
> - I load a minidump, without any supporting files around
> - I see that my object file is missing, I do some digging around, and manage to find the stripped object file for this module
> - I do "target modules replace index_of_placeholder_module /path/to/elf.stripped"
> - now my sections are there, but I still don't have symbols
> - I do more digging and find the breakpad file
> - I do "target symbols add /path/to/breakpad.syms"
> - success. I now have both symbols and sections
> 
> Now this is probably not the most common scenario, but I think it can be used as a benchmark to see if the infrastructure is set up the right way. If things are set up correctly this should work out-of-the-box. With your setup, the scenario above might "just work" if I execute "target symbols add" twice (with different files), because the second "target symbols add" will do something different than the first one, but that sounds to me like another reason why these should be different commands.
> 
> Maybe there should be there should be some code to help the user and detect the situation when he is adding a symbol file to a placeholder module and the symbol file is able serve as a good object file too, but that code could live higher up than Module::GetObjectFile. It could perhaps be directly in the "target symbols add" command via something like:
> if (module_I_am_about_to_add_symbols_to->IsPlaceholder() && symbol_file->ContainsGoodObjectFileRepresentation())
>  TargetModulesReplace(module_I_am_about_to_add_symbols_to, symbol_file)
> else
>  the_module_I_am_about_to_add_symbols_to->SetSymbolFile(symbol_file)

I like the replace idea. Another scenario this will fix is when you start debugging with a stripped object file straight from a device, and later download the unstripped version and want to replace it. We will need to make sure all breakpoints get unresolved and re-resolved correctly in testing. Also, stack frames should get flushed as they do when we do "target symbols add"



More information about the lldb-commits mailing list