mac dump_syms missing some source files

[GoogleCodeExporter]

It looks like the mac dump_syms might be missing some source files on ppc
binaries.  I have a concrete example here:
https://crash-reports.mozilla.com/reports/report/index/4ed78175-1a03-11dc-8620-0
01a4bd43ed6

The top frame of the stack, nsIPresShell::RemoveWeakFrame(nsWeakFrame*) is
listed as being in nsCSSParser.cpp, when it's actually in nsPresShell.cpp:
0|0|firefox-bin|nsIPresShell::RemoveWeakFrame(nsWeakFrame*)|/builds/tinderbox/Fx
-Trunk/Darwin_8.8.4_Depend/mozilla/layout/style/nsCSSParser.cpp|2104|0x14
nsPresShell.cpp doesn't appear in the dump_syms output anywhere.

Here's the dump_syms output for that module for ppc:
http://symbols.mozilla.org/firefox/firefox-bin/47908C35375D47EA705A80128E5B94100
/firefox-bin.sym
and for i386:
http://symbols.mozilla.org/firefox/firefox-bin/54B144F3DAC21AFB056E8C7CE01100310
/firefox-bin.sym

nsPresShell.cpp does show up in the i386 output.  I've done a little bit of
poking, and in dump_syms.mm, in processSymbolItem, the source file doesn't
show up in the if (list->n_type == N_SO) {} block.  Running objdump on the
same binary shows that source file existing somewhere, although I don't
know how to interpret the output properly.

I'm sort of stuck at this point.  This is occurring in our nightly Firefox
builds, and I can reproduce it in a cross-compiled ppc build on my machine.

Original issue reported on code.google.com by ted.mielczarek on 15 Jun 2007 at 3:32

[GoogleCodeExporter]

Apparently it is present on intel as well:
https://bugzilla.mozilla.org/show_bug.cgi?id=393317

Original comment by ted.mielczarek on 22 Aug 2007 at 11:46

• Changed title: mac dump_syms missing some source files

[GoogleCodeExporter]

http://people.mozilla.com/~tmielczarek/XUL.bz2

This is at least related, if not exactly the same issue.  This binary misses
txInstructions.h, so a whole bunch of constructors/destructors wind up listed 
in the
wrong source file.  You can run dump_syms, and look for 
txEndElement::~txEndElement
in the output, it gets listed in cairo-hull.c, which is definitely wrong.  See a
pretty bad example of this here:
http://crash-stats.mozilla.com/report/index/ecf96154-c01a-11dc-ad73-001a4bd43ef6
?date=2008-01-11-07#frames

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

[GoogleCodeExporter]

Ok, this definitely shows the original problem, even if that
txEndElement::~txEndElement isn't the same problem.  If you grep the output for
nsInstallTrigger::nsInstallTrigger, you'll find it listed in source file 1212, 
which
is mozilla/xpinstall/src/CertReader.cpp, which is wrong. 
mozilla/xpinstall/src/nsInstallTrigger.cpp, the file containing that class
implementation, is completely skipped.

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

[GoogleCodeExporter]

Ted, do you still run into this with DWARF?

Original comment by neal...@gmail.com on 22 Feb 2009 at 7:47

[GoogleCodeExporter]

From a brief grep of our latest symbols, it looks ok, so I'm willing to guess 
it's fixed.

Original comment by ted.mielczarek on 26 Feb 2009 at 1:16

• Changed state: Fixed