<div dir="ltr">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).<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 30, 2015 at 10:31 AM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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...<br>
<br>
Jim<br>
<br>
> On Jul 30, 2015, at 9:58 AM, Ed Maste <<a href="mailto:emaste@freebsd.org" target="_blank">emaste@freebsd.org</a>> wrote:<br>
><br>
> On 30 July 2015 at 12:14, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
>> Would be great if we had a test that verified this.  I think we could do<br>
>> this by making a small program that gets its own main thread id at runtime<br>
>> and stores it in a local variable.  Generate a core dump while stopped at a<br>
>> breakpoint right after the variable is initialized.  Then have the test<br>
>> verify that whatever command reports the current thread is has the same<br>
>> value as the variable.<br>
><br>
> Yes, we definitely need tests. We've discussed core file tests a bit<br>
> in the past, but haven't come to a resolution as I recall.<br>
><br>
> I'm not a fan of generating cores on the fly in the tests; we should<br>
> be able to test core loading for all supported targets, and I'd rather<br>
> not spam system logs with crash reports in order to run a test. I<br>
> think we could instead just commit a set of test executables and<br>
> associated core files to the repository. Some effort is probably<br>
> necessary to reduce the size of core files on certain operating<br>
> systems -- on FreeBSD we end up with core files of at least ~4MB, due<br>
> to malloc defaults.<br>
><br>
> I started working on collecting userland core files from various<br>
> operating systems a while back:<br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_emaste_userland-2Dcores&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=DDUMf06MYELAe1Nlv7KChiwJLLHbYha4jtK_AOiWqwQ&m=U3eJKCc1dvqRcFQsRPOV7R6zzGx144oyWzT-DlBq-a0&s=bEsyJvneaW1jAA24hga2dXmxpIym4oFGhF3o3Hqt1o0&e=" rel="noreferrer" target="_blank">https://github.com/emaste/userland-cores</a><br>
> I can take another look with a goal of producing a representative<br>
> sample that could be used for LLDB tests.<br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div>