We only have an x64 architecture; we invoke dsymutil several times for the frameworks and the plugin bundles, but only once for the main executable, like this
dsymutil /Volumes/Work/D-084/Bin.Mactel/Programs_GCC4_2_64_LLVM.dev/ArchiCAD\ 16.app/Contents/MacOS/ArchiCAD -o /Volumes/Work/D-084/Bin.Mactel/Programs_GCC4_2_64_LLVM.dev/Support/MAPs/Arc hiCAD 16.dsym Is it a problem that the .app has a different name than the executable? Or the dSYM file is created in a separate folder? If I do a clean debug build, then the dsym file is created fine. If I do an incremental build, then the dsym file is created only partially, and I cannot see the source when debugging the main executable's code. Breakpoints in the other frameworks work fine; I can step through the source. I also tried to create a flat dSYM file, to no avail. With verbose logging turned on, I got a bit more than 11 000 lines like this: "address information attributes will be removed because there is no relocation address" Thanks, Ákos Somorjai Developer Support Manager GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 | [email protected] On 9/23/11 7:20 PM, "Greg Clayton" <[email protected]> wrote: >Looks like dsymutil bailed when it couldn't write the mach-o dSYM file. > >Are you invoking dsymutil yourself multiple times? If you have a fat >file, you probably want to wait until you have your universal final >binary, and run dsymutil on it. > >Let me know what your invocation of dsymutil looks like and how/where it >is used in your builds (on each individual arch slice, or on the >universal result, or only on one arch)? > >On Sep 23, 2011, at 7:49 AM, Somorjai, Akos wrote: > >> Hello greg, >> >> Further info after running dwarfdump on the partially written dSYM file: >> >> dwarfdump >>/Volumes/Work/D-084/Bin.Mactel/Programs_GCC4_2_64_LLVM.dev/Support/MAPs/A >>rchiCAD\ 16.dsym >> ---------------------------------------------------------------------- >> File: >>/Volumes/Work/D-084/Bin.Mactel/Programs_GCC4_2_64_LLVM.dev/Support/MAPs/A >>rchiCAD 16.dsym/Contents/Resources/DWARF/ArchiCAD.x86_64 (x86_64) >> ---------------------------------------------------------------------- >> warning: (x86_64) __DWARF.__debug_info section has offset (0x02544a80) >>that is beyond the end (0x02544a80) of architecture slice in >>'/Volumes/Work/D-084/Bin.Mactel/Programs_GCC4_2_64_LLVM.dev/Support/MAPs/ >>ArchiCAD 16.dsym/Contents/Resources/DWARF/ArchiCAD.x86_64' >> .debug_info contents: >> < EMPTY > >> >> Do you have any clues? >> >> Thanks, >> Ákos Somorjai >> Developer Support Manager >> >> GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 >>| [email protected] >> >> >> >> From: Ákos Somorjai <[email protected]> >> Date: Fri, 23 Sep 2011 15:28:03 +0200 >> To: Greg Clayton <[email protected]> >> Cc: "[email protected]" <[email protected]> >> Subject: Re: [lldb-dev] Problem with large sym files >> >> Hello Greg, >> >> I'm running into another problem with dsymutil; it can't extract the >>dsym information from our main executable (> 200 MB in size) when >>building the debug version repeatedly. I get the following error message: >> >> error: unable to restore file position to 0x00000c58 for section >>__DWARF.__debug_info >> >> Any ideas? >> >> Thanks, >> Ákos Somorjai >> Developer Support Manager >> >> GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 >>| [email protected] >> >> >> >> Date: Tue, 20 Sep 2011 17:24:15 +0200 >> To: Greg Clayton <[email protected]> >> Cc: "[email protected]" <[email protected]> >> Subject: Re: [lldb-dev] Problem with large sym files >> >> Hello Greg, >> >> Thanks for the useful information! >> >> Moving to dSYM files really helped, now I can debug ArchiCAD on my >>machine. The dSYM option was already set for the distribution build, so >>it was an easy change. Is there any other way besides using dsymutil to >>produce those files? >> >> I'm also looking forward to the large memory improvements you >>mentioned; shall I check out the trunk and compile lldb from source? >> >> We are using an external make file system (Perforce's Jam based), so >>building in Xcode is not an issue. Though it seems that even in this >>case Xcode holds onto the loaded symbols files between debugging >>sessions. >> >> Another question: are the planned improvements making their way into >>the Xcode 4.2 GM? >> >> I'm very pleased that you are addressing the large application issues. >> >> Best, Akos >> >> On Sep 20, 2011, at 6:28 AM, Greg Clayton wrote: >> >>> 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
