[lldb-dev] Do we have any infrastructure for creating mini dump files from a loaded process or from a core file?

Wed Jun 13 15:49:42 PDT 2018

For core -> minidump conversion, a Python tool might end up as trivial as:

process = target.LoadCore(source_core_file)
process.SaveMinidump(output_minidump_file)

Another angle on reusing existing minidump writing code: we could reuse
just the minidump file creation from Crashpad (the part which constructs
the minidump datastructures and puts together the final minidump file)
without the "process parsing" part of Crashpad (since LLDB already covers
that)

If anyone is interested in exploring that, the interface to this low level
minidump writing part is crashpad::ProcessSnapshot
<https://chromium.googlesource.com/crashpad/crashpad/+/master/snapshot/process_snapshot.h>
& the rest of the xxxSnapshot interfaces.

On Wed, Jun 13, 2018 at 3:33 PM, Jim Ingham <jingham at apple.com> wrote:

> Greg already wrote a "save_crashlog" Python command that writes the state
> of the program as a macOS flavor Crashlog file.  It's in
> examples/Python/crashlog.py.  My guess is he had something similar to that
> in mind, but writing a mini dump file instead.
>
> Jim
>
>
> > On Jun 13, 2018, at 3:20 PM, Leonard Mosescu via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >
> > What about the case where you already have a Unix core file and you
> aren't in a debugger but just want to convert it?
> >
> > Just curious, would a small Python script using the LLDB SB API satisfy
> this requirement?
> >
> >  We could move all the code for consuming and producing Windows
> minidumps and Unix / Mach-O corefiles from LLDB down into LLVMCoreFile,
> write a library like llvm-core that can manipulate or inspect them, then
> have LLDB use it.  Kill 2 birds with one stone that way IMO.
> >
> > I like the idea of factoring out reusable subsystems, and I'd love to
> see something along these lines. Just a word of caution though: the hard
> part may not be the generation of a "structurally valid" minidump file, but
> "parsing" and modeling the process state (figuring out the list of modules
> & memory regions, etc. See the Crashpad implementation for details).
> >
> > On Wed, Jun 13, 2018 at 3:01 PM, Zachary Turner via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> > Yea, I think something like this would actually make a useful llvm
> utility.  Call it llvm-core or something, and it links against the library
> LLVMCoreFile.  We could move all the code for consuming and producing
> Windows minidumps and Unix / Mach-O corefiles from LLDB down into
> LLVMCoreFile, write a library like llvm-core that can manipulate or inspect
> them, then have LLDB use it.  Kill 2 birds with one stone that way IMO.
> >
> > On Wed, Jun 13, 2018 at 2:56 PM Jason Molenda <jmolenda at apple.com>
> wrote:
> > fwiw I had to prototype a new LC_NOTE load command a year ago in Mach-O
> core files, to specify where the kernel binary was located.  I wrote a
> utility to add the data to an existing corefile - both load command and
> payload - and it was only about five hundred lines of C++.  I didn't link
> against anything but libc, it's such  a simple task I didn't sweat trying
> to find an object-file-reader/writer library.  ELF may be more complicated
> though.
> >
> > > On Jun 13, 2018, at 2:51 PM, Zachary Turner via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> > >
> > > What about the case where you already have a Unix core file and you
> aren't in a debugger but just want to convert it?  It seems like we could
> have a standalone utility that did that (one could imagine doing the
> reverse too).  I'm wondering if it wouldn't be possible to do this as a
> library or something that didn't have any dependencies on LLDB, that way a
> standalone tool could link against this library, and so could LLDB.  I
> think this would improve its usefulness quite a bit.
> > >
> > > On Wed, Jun 13, 2018 at 2:42 PM Greg Clayton <clayborg at gmail.com>
> wrote:
> > > The goal is to take a live process (regular process just stopped, or a
> core file) and run "save_minidump ..." as a command and export a minidump
> file that can be sent elsewhere. Unix core files are too large to always
> send and they are less useful if they are not examined in the machine that
> they were produced on. So LLDB gives us the connection to the live process,
> and we can then create a minidump file. I am going to create a python
> module that can do this for us.
> > >
> > > Greg
> > >
> > >
> > >> On Jun 13, 2018, at 2:29 PM, Zachary Turner via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> > >>
> > >> Also, if the goal is to have this upstream somewhere, it would be
> nice to have a tool this be a standalone tool.  This seems like something
> that you shouldn't be required to start up a debugger to do, and probably
> doesn't have many (or any for that matters) on the rest of LLDB.
> > >>
> > >> On Wed, Jun 13, 2018 at 1:58 PM Leonard Mosescu <mosescu at google.com>
> wrote:
> > >> That being said, it's not exactly trivial to produce a good minidump.
> Crashpad has a native & cross-platform minidump writer, that's what I'd
> start with.
> > >>
> > >> Addendum: I realized after sending the email that if the goal is to
> convert core files -> LLDB -> minidump a lot of the complexity found in
> Crashpad can be avoided, so perhaps writing an LLDB minidump writer from
> scratch would not be too bad.
> > >>
> > >> On Wed, Jun 13, 2018 at 1:50 PM, Leonard Mosescu <mosescu at google.com>
> wrote:
> > >> The minidump format is more or less documented in MSDN.
> > >>
> > >> That being said, it's not exactly trivial to produce a good minidump.
> Crashpad has a native & cross-platform minidump writer, that's what I'd
> start with.
> > >>
> > >> On Wed, Jun 13, 2018 at 1:38 PM, Adrian McCarthy via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> > >> Zach's right.  On Windows, lldb can produce a minidump, but it just
> calls out to a Microsoft library to do so.  We don't have any
> platform-agnostic code for producing a minidump.
> > >>
> > >> I've also pinged another Googler who I know might be interested in
> converting between minidumps and core files (the opposite direction) to see
> if he has any additional info.  I don't think he's on lldb-dev, though, so
> I'll act as a relay if necessary.
> > >>
> > >> On Wed, Jun 13, 2018 at 12:07 PM, Zachary Turner via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> > >> We can’t produce them, but you should check out the source code of
> google breakpad / crashpad which can.
> > >>
> > >> That said it’s a pretty simple format, there may be enough in our
> consumer code that should allow you to produce them
> > >>
> > >>
> > >> _______________________________________________
> > >> lldb-dev mailing list
> > >> lldb-dev at lists.llvm.org
> > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> lldb-dev mailing list
> > >> lldb-dev at lists.llvm.org
> > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> lldb-dev mailing list
> > >> lldb-dev at lists.llvm.org
> > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > >
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb-dev at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180613/5240b803/attachment.html>