handle inlined methods properly in dump_syms

[GoogleCodeExporter]

The Mac OS X dump_syms tool doesn't handle inlined methods properly.  It
shows the line number from the file where the inlined method originates,
but the source file ID for the file containing the current method.  This
was fixed for Linux over in issue 235.  You can see an example of this
using this binary: http://people.mozilla.com/~tmielczarek/XUL.bz2

In the dump_syms output, search for GetWordFontOrGroup.  The output looks
like so:
UNC 7ffab8 87 0 GetWordFontOrGroup(gfxTextRun*, unsigned int, unsigned int)
7ffab8 10 175 1552
7ffac8 8 66 1552
7ffad0 6 1229 1552
7ffad6 12 179 1552
7ffae8 3 942 1552
7ffaeb 12 181 1552
7ffafd e 182 1552
7ffb0b 2 183 1552
7ffb0d 7 190 1552
7ffb14 12 186 1552
7ffb26 6 187 1552
7ffb2c 7 188 1552
7ffb33 7 190 1552
7ffb3a 6 699 1552

File 1552 is mozilla/gfx/thebes/src/gfxTextRunWordCache.cpp, which contains
that method:
http://lxr.mozilla.org/mozilla/source/gfx/thebes/src/gfxTextRunWordCache.cpp#174
.
 That file does not have 1229 lines though, so it seems likely that that's
an inlined method.  (Also the line 66 before it is pretty suspect.)  For
the Linux case, luly had to handle N_SOL records and store the source file
ID for later inclusion.

Original issue reported on code.google.com by ted.mielczarek on 11 Jan 2008 at 10:12

[GoogleCodeExporter]

This works fine with the DWARF symbol dumper, fwiw.

Original comment by ted.mielczarek on 21 Jan 2009 at 2:25

[GoogleCodeExporter]

Doesn't seem worth fixing now that we have DWARF.

Original comment by ted.mielczarek on 4 Sep 2009 at 7:07

• Changed state: WontFix