Does liblldb-core.a really need to be 763MB in siz

Question

This definitely takes the cake in terms of being the largest single piece of executable code I have ever seen.

Now it was a bit easier to get this whole thing built on my Mac here (I have been trying to build LLDB on a Linux as well, and currently I'm fighting with linking to Python there), for which I am thankful, but this astoundingly large executable file has me second-guessing myself... Did I do something wrong? What is inside of this monstrous archive?

I did run this:

% otool -TV liblldb-core.a

It produces 1159 lines of output, which puts it around 350+ object files. That sounds about right, I saw the XCode project work its way through about 350 source files.

I guess my question is why does LLDB work this way, why isn't it a bit more lightweight and why doesn't it just link to LLVM and Clang code rather than doing whatever this is? OR, are the contents of this archive already ALL LLDB-specific code? I recognize building a debugger is quite the undertaking, but this is honestly just mind-boggling.

I am aware that compiling at -O3 likely bloats executable file size. I'm not about to go back and recompile this monster though (the computer nearly melted with smcFanControl reporting CPU core temps as high as 106 degrees C).

Update: I sort of chronicled some further learning I just did over here... I'm still not able to find a monstrous liblldb-core.a or anything of the sort inside of XCode.app, and I'm still a bit confused about how this whole thing works.

Answer 1

It's the debug info that's the real issue with liblldb-core.a. Around 720MB of the 750MB is DWARF. (You can test this yourself - ar x liblldb-core.a into a directory, then strip -S *.o and you'll have about 32MB of .o files.) DWARF without real type uniquing has some nasty bloat with C++ programs.

I can make a .tar.gz of the (stripped) LLDB framework and lldb driver program and they come in at around 10MB or so with that compression -- and this is after linking in all of the llvm and clang bits needed by lldb. Nothing particularly outrageous here, even if the intermediate steps can look crazy.

Answer 2

I should have noticed that I took that first screenshot inside the Debug build directory which indicates that it is huge potentially because of the build configuration I had used.

Edit: Nope, that isn't quite the answer. The Release directory actually contains a liblldb-core.a that is slightly bigger than the other one.

It does appear that this huge 700MB archive is some sort of "side effect" file. When I archived the project it produced a 369MB .xarchive file. I'm sure this is a better representation of the "content" here. I am still basically learning this stuff by stumbling over it in the dark...

Update:

Oh, okay, looking at this situation it makes a bit more sense:

I took these files out of the Release directory after building it in Xcode (and minimally tweaking it to use -O3 for Release). I can see here that the ~350MB dSYM file containing debug information is taking up the majority of the space of that .xarchive from earlier, and that actually lldb's executable code totals under 40MB in size, the majority of which resides in that framework in an executable named LLDB.

This is a lot more reasonable to me. Now that I've gotten it out of Xcode and into my Documents directory where I can be more assured no external program would delete or modify it without my knowing, I can feel good about symlinking it from here to /usr/lib/lldb.