[lldb-dev] Question (bug?) about thread tids when lldb loads a core dump.

[Zachary Turner]

Hmm, so the way this works on Windows is that inside the core file are the
names of libraries along with a corresponding hash of the library.  When
the core file is read, the debugger searches a pre-defined set of locations
for symbol information for the libraries (a symbol file which claims to
match the name and hash of the library written in the core).

Has any thought ever been given to doing something like this on Mac?  It
seems a little wasteful to have every core file duplicate the same
information about system libraries.

Even easier, what about a flag when generating a core that just says "don't
write system libraries into the core"?  Sure, it might degrade the
debugging experience, but I think there's still some basic things you can
do without that information.

For Windows core file tests I had planned to just make these lightweight
core files (in the windows universe these are called "minidumps"), which
are usually less than 100KB.

On Thu, Jul 30, 2015 at 10:31 AM Jim Ingham <jingham at apple.com> wrote:

> User-level core files on Mac OS X are huge (500MB for a nothing app).
> This is because most of the system libraries are munged into a unified
> "shared cache" and that gets written out in toto in the core.  Just a heads
> up...
>
> Jim
>
> > On Jul 30, 2015, at 9:58 AM, Ed Maste <emaste at freebsd.org> wrote:
> >
> > On 30 July 2015 at 12:14, Zachary Turner <zturner at google.com> wrote:
> >> Would be great if we had a test that verified this.  I think we could do
> >> this by making a small program that gets its own main thread id at
> runtime
> >> and stores it in a local variable.  Generate a core dump while stopped
> at a
> >> breakpoint right after the variable is initialized.  Then have the test
> >> verify that whatever command reports the current thread is has the same
> >> value as the variable.
> >
> > Yes, we definitely need tests. We've discussed core file tests a bit
> > in the past, but haven't come to a resolution as I recall.
> >
> > I'm not a fan of generating cores on the fly in the tests; we should
> > be able to test core loading for all supported targets, and I'd rather
> > not spam system logs with crash reports in order to run a test. I
> > think we could instead just commit a set of test executables and
> > associated core files to the repository. Some effort is probably
> > necessary to reduce the size of core files on certain operating
> > systems -- on FreeBSD we end up with core files of at least ~4MB, due
> > to malloc defaults.
> >
> > I started working on collecting userland core files from various
> > operating systems a while back:
> > https://github.com/emaste/userland-cores
> > I can take another look with a goal of producing a representative
> > sample that could be used for LLDB tests.
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150730/95ce16cd/attachment.html>