Thanks, Greg, partly. dsymutil's speed is still a problem for everyday's work (the modify-build-debug cycle takes 10 minutes. And gdb bails out when trying to debug an executable compiled with -flimit-debug-info. This last one is again a real catch-22, because:
- if I compile the debug and release builds with -flimit-debug-info and llvm, then the only way to debug it is with lldb. If this proves to be unbearably slow, then I'd have to switch back to gdb, which can't read the symbol info :( - if I compile without limiting the debug info size using llvm, then I won't be able to use dsymutil on the executable (which is a problem for release builds), but then I can debug with gdb (which is sort of OK for the debug, but not for release builds) The whole point of moving to llvm and lldb would be to increase productivity, but at the moment I don't see the light at the end of the tunnel. Let me experiment a little more with the compiler options and the debuggers; I'll send you the results this week. Thanks for the great support, Ákos On 9/28/11 7:38 PM, "Greg Clayton" <[email protected]> wrote: >Much better. Nothing we need to look into then, dsymutil was just >erroring out due to the limitations of the mach file format only being >able to handle 4GB of data. I can conjure up a test case here that blows >out the 4GB limit. > >Everything good on your end now? > >Greg _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
