> On Dec 11, 2018, at 7:14 AM, Pavel Labath <pa...@labath.sk> wrote: > > On 11/12/2018 01:08, Greg Clayton wrote: >>> On Dec 10, 2018, at 3:11 PM, Leonard Mosescu <mose...@google.com >>> <mailto:mose...@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" _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
