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

[Pavel Labath via lldb-commits]

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)