1617246 - Allow reading symbols from the objdir when symbolicating a stripped packaged local build

Status: RESOLVED FIXED

(DevTools :: Performance Tools (Profiler/Timeline), enhancement, P3)

Description

[Markus Stange [:mstange]]

Steps to reproduce:

1. Create a local build on macOS using ./mach build.
2. Create a packaged build from this using ./mach package.
3. Run the packaged build, for example as follows: obj-x86_64-apple-darwin18.6.0/dist/firefox/Nightly.app/Contents/MacOS/firefox -P debug -foreground --no-remote
4. Enable the profiler toolbar icon.
5. In the "Local build" section in the profiler toolbar icon's dropdown arrow panel, add your objdir.
6. Grab a profile.

Expected results:
The resulting profile should have full symbol information for the XUL library.

Actual results:
The resulting profile has bad symbols. Example: https://perfht.ml/38N6BG9

The incomplete symbols happen because mach package strips out symbols from our binaries, unless ac_add_options --disable-install-strip is present in the mozconfig. So dist/firefox/Nightly.app/Contents/MacOS/XUL now has an incomplete symbol table, and we use that incomplete symbol table to symbolicate the profile.
However, the symbols are still present in the original binary at dist/bin/XUL, so we should be able to use this original file to symbolicate the profile. The code for this exists, I think it's just not hooked up in the right place.
(More precisely: dist/bin/XUL is a symlink to the original at toolkit/library/build/XUL.)

Comment 1

[Markus Stange [:mstange]]

There's an easy workaround for this: you can just copy the unstripped libxul over the stripped one. This won't do anything to the .dmg bundle but that doesn't matter if you're not executing from the dmg bundle anyway.

E.g. execute this from the objdir:

cp toolkit/library/build/XUL dist/firefox/Nightly.app/Contents/MacOS/XUL

Comment 2

[Markus Stange [:mstange]]

Attachment: Bug 1617246 - Always consult objdirs for symbols.

This duplicates the functions getSymbolTableFromLocalBinary and doesFileExistAtPath between browser.js and background.jsm.js.
I haven't looked into how best to share this code.

The other thing I'm not sure about is the call to getRecordingPreferencesFromBrowser() in getSymbolsFromThisBrowser.
That's how it gets the list of configured objdirs: const objdirs = getRecordingPreferencesFromBrowser().objdirs;
I don't know if this is the right thing to do or if the information should be propagated in some other way.

Comment 3

[Markus Stange [:mstange]]

Unassigning for now. The workaround is simple enough that this is not an immediately pressing issue. The patch does seem to work though.

Comment 4

[Markus Stange [:mstange]]

This patch also helps with other cases in which the original pdb file is at an unexpected path, for example when launching a build from a network share (bug 1585461). I'll try to finish it up.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b9c36547e226
Always consult objdirs for symbols. r=gregtatum

Comment 6

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/b9c36547e226