DWARF support for Mach-o binaries in dump_syms tool on Mac OS X

[GoogleCodeExporter]

I know that issue #130 tracks this for Linux, but since the latest Mac OS X 
Developer Tools also 
support DWARF symbols, this is also of interest for the Mac OS X (especially in 
the light that DWARF 
is now the symbol format is now the default symbol format and produces much 
smaller 
executables, so it's likely to be used in many projects).

Original issue reported on code.google.com by j...@mac.com on 11 Jan 2008 at 9:48

[GoogleCodeExporter]

Original comment by ted.mielczarek on 11 Jan 2008 at 9:04

• Added labels: Component-Tool-SymConverter, OpSys-OSX

[GoogleCodeExporter]

Just as a heads-up, I have a big pile o' code that does all this and produces
generally plausible-looking sym files for trunk Mozilla built on 10.5. It 
includes a
line number state machine that will be re-usable on Linux without too much 
trouble,
plus some messy hackery to deal with dwarf info in .o files, since the info 
doesn't
get copied/linked into the final executable or dylib. It needs more cleanup, 
then I
plan to post it for review.

Original comment by stansh...@gmail.com on 21 Apr 2008 at 8:01

[GoogleCodeExporter]

OK, here is a review-suitable patch. It mixes in some minor 64-bit fixes, 
though not
enough to get dump_syms fully functional on 64-bit executables. This has been
exercised on the 180-odd executables of the Moz trunk built on Leopard, and 
shows no
regressions in stabs builds on Tiger. The dwarf line number state machine 
pretty much
mimicks the spec, and it's the simple part; the hard parts are the code to get 
info
from .o files and archive members, for which I do a bit of recursion, 
complicated by
the need to handle unrelocated addresses.

Original comment by stansh...@gmail.com on 24 Apr 2008 at 2:41

Attachments:

• dwarf-breakpad-patch-4

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by neal...@gmail.com on 15 Jun 2008 at 6:33

Attachments:

• dwarf-rev2.diff

[GoogleCodeExporter]

Original comment by neal...@gmail.com on 25 Sep 2008 at 5:30

Attachments:

• breakpad-dwarf-patch.0925

[GoogleCodeExporter]

Tried to apply breakpad-dwarf-patch.0925 and found a couple of issues:

(1) had to manually rename src/tools/mac/dump_syms/dump_syms.m to dump_syms.mm

(2) the NSLog call in dump_syms.mm:631 has a case typo - the variable passed 
should be "sourcePath_", not 
"sourcepath_"

(3) the line dump_syms.mm:1065 should read
    sourcePath_ = [[path copy] stringByAppendingPathExtension:@"dSYM"];
instead of
    sourcePath_ = [path copy];

Original comment by j...@mac.com on 25 Sep 2008 at 7:03

[GoogleCodeExporter]

Hi,
Thanks for looking at this.
1) Right, because of how SVN patches work, anyone who's applying the patch 
needs to
do "svn copy dump_syms.m dump_syms.mm" first

2) Removed, thanks for catching this. I had added it for some debugging but I 
must
have rebuilt the wrong copy and removing it dropped through the cracks

3) I'm not sure if we should manually append a dSYM extension rather than use 
what
the user has passed in on the command line - this way, if the user passes a 
binary
that contains DWARF information but isn't part of a dSYM bundle we can still 
read it

Original comment by neal...@gmail.com on 25 Sep 2008 at 4:19

[GoogleCodeExporter]

regarding 3):
Yes, you're right - didn't realize that of course, the dSYM bundle is all 
that's needed to dump the symbols...

Original comment by j...@mac.com on 26 Sep 2008 at 6:56

[GoogleCodeExporter]

before applying patch, do(from root of checkout):
1) svn copy src/tools/mac/dump_syms/dump_syms_tool.m
src/tools/mac/dump_syms/dump_syms_tool.mm

2) patch -p0 < <patch path>

Then run the following commands:

svn add src/common/mac/dwarf
svn add src/client/mac/handler/testcases/testdata/
svn add src/client/mac/handler/testcases/dwarftests.h
svn add src/client/mac/handler/testcases/dwarftests.mm
svn add src/client/mac/handler/obj-cTestCases-Info.plist

THEN, if you want to run the tests, download the attached
binary(dump_syms_dwarf_data), which will be checked in when this is code 
reviewed,
and place it in src/client/mac/handler/testcases/testdata (separate step 
because svn
diff skips binary files)

Original comment by neal...@gmail.com on 7 Oct 2008 at 10:12

Attachments:

• dwarf.1007
• dump_syms_dwarf_data

[GoogleCodeExporter]

This patch renames some #include guards

Original comment by neal...@gmail.com on 7 Oct 2008 at 10:32

Attachments:

• dwarf.1007

[GoogleCodeExporter]

Original comment by ted.mielczarek on 1 Dec 2008 at 8:22

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for integrating this.
I tried rev 299 and I can now properly dump DWARF symbols. However, I only see 
C and Objective-C symbols 
when I use stackwalker or crash_report to resolve the minidump (using the sym 
files generated from the external 
dSYM DWARF symbols), but no C++ symbols at all.

When I generate the sym files from the executables, I do see C, C++ and 
Objective-C symbols, but of course 
without source file and line (we're using external DWARF symbols, aka dSYM 
files).

Original comment by j...@mac.com on 5 Dec 2008 at 8:33

[GoogleCodeExporter]

You probably need the followup patches in issue 283 and issue 284. They should 
land
in SVN shortly.

Original comment by ted.mielczarek on 5 Dec 2008 at 1:18