This patch introduces a small utility program to extract a guid from a shared library
or executable on windows to identify the correct symbol file to read in fix_stack_using_bpsyms.py.
In order for this to work correctly on windows, the library name provided by
MozDescribeCodeAddress needs to be a full path, so the LoadedImageName field
from the IMAGEHLP_MODULE64 structure is used here instead of the ModuleName
field.
MozReview-Commit-ID: 8zkfLWjKVs2
This patch introduces a small utility program to extract a guid from a shared library
or executable on windows to identify the correct symbol file to read in fix_stack_using_bpsyms.py.
In order for this to work correctly on windows, the library name provided by
MozDescribeCodeAddress needs to be a full path, so the LoadedImageName field
from the IMAGEHLP_MODULE64 structure is used here instead of the ModuleName
field.
fix_stack_using_bpsyms.py locates a .sym file based on file name only, not uuid or full path,
which causes a failure if a duplicate leaf file name is introduced. This patch introduces a
small utility program on mac and linux to extract a breakpad guid from a shared library or
executable to identify the correct symbol file when this ambiguity occurs. A subsequent commit
implements this for windows.
This is needed to avoid regressions relative to the perl version because
the perl version failed, due to a missing /, to properly examine two of
the paths, one of which often yields the same filename as the original
file (but whose CRC will fail).
I've tested that this CRC calculation succeeds in cases where it should
succeed.
The observed CRC check failures (so far) on my Ubuntu 14.04 system are
the following links:
/lib/x86_64-linux-gnu/libc.so.6 -> /lib/x86_64-linux-gnu/libc-2.19.so
/lib/x86_64-linux-gnu/libpthread.so.0 -> /lib/x86_64-linux-gnu/libpthread-2.19.so
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 -> /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 -> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.23
which succeed on a later possibility in /usr/lib/debug/. But optimizing
to check f != file before checking the CRC wouldn't help because of the
naming differences due to symlinks, so I didn't bother. If we ever want
to optimize away the time doing the CRC checks for these failures, we
could do so by checking if the files are the same path *after* resolving
symlinks.
DONTBUILD
Now that bug 975295 removed the obsolete wrapper class, we can rename
nsTraceRefcntImpl back to its correct pre-XPCOM-glue name,
nsTraceRefcnt.
The best part is that the one place where indentation should have needed
fixing, nsTraceRefcnt::DemangleSymbol, never had its indentation fixed
for the previous renaming.
--HG--
rename : xpcom/base/nsTraceRefcntImpl.cpp => xpcom/base/nsTraceRefcnt.cpp
rename : xpcom/base/nsTraceRefcntImpl.h => xpcom/base/nsTraceRefcnt.h
