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

[Leonard Mosescu via lldb-commits]

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 <clayborg at gmail.com> wrote:

>
>
> > 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"
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20181211/81e0e12a/attachment-0001.html>