I made some large memory improvements a few days ago which should help with 
this issues, so the issue is actively being worked on.

One thing you can do that might improve things for debugging with LLDB is to 
create dSYM files for any binaries that you debug. With the DWARF in the .o 
files, we end up with a ton of debug info and a large memory footprint, which 
again, I just submitted a fix for this a few days ago and this hasn't made it 
into a build yet.

So try making dSYM files and see if this helps. There is also a compounding 
issue going on in the Xcode builds where Xcode holds onto references to our 
symbol files between builds (we have a radar for this) so each time you modify 
and rebuild and debug again, we still have a copy of the old stuff in memory, 
so you end up with two copies of the LLVM/Clang executables and debug info. 
This can only be cured by quitting and restarting Xcode and we do have a fix on 
the way in the next release.

So for now try:
- making dSYM files for all executables you want to debug
- quit Xcode if you end up rebuilding and linking after a few builds

We also have new accelerator tables  we are building into the compilers and 
into the dSYM files that will greatly help with this issue (speed and memory).

Greg Clayton


On Sep 19, 2011, at 6:16 AM, Somorjai, Akos wrote:

> Hello everyone,
> 
> I've just recently started to convert our codebase to LLVM 3.0, and also gave 
> a try to debugging with LLDB. And that's where I ran into a serious wall: 
> lldb is unable to load the sym files for our main executable (not to mention 
> the numerous shared libraries it uses). I'm using LLDB-75 on Mac OS X 10.6.8 
> on a Core i7 MacBook Pro, have 8 GB memory, the sym format is DWARF-2.
> 
> Well, it loads the sym files after 15 mins or so, but then setting a 
> breakpoint also took 10 mins, and step one line during debugging is another 
> 15 mins.
> 
> At the end of the process Xcode used 35 GBs of virtual and 6.5 GBs of real 
> memory (according to the Activity Monitor).
> 
> Is there anything I can do about it?
> 
> GDB handles this situation quite gracefully…
> Thanks,
> 
> Ákos Somorjai
> Developer Support Manager
> 
> GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 | 
> [email protected]
> 
> 
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to