Thanks Pavel and Greg. 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.
Yes, that would be my preference as well. Imagine the following scenario: > - I load a minidump, without any supporting files around ... I'd like to support the "other" variation as well: we start with a minidump, load the symbols, _then_ dig for some module's binary (for example if we really need image bits that are not captured in the minidump) On Tue, Dec 11, 2018 at 9:50 AM Greg Clayton <clayb...@gmail.com> wrote: > > > > 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
