It would be nice if we had an --enable-debuglink flag to configure to make the build system strip out debug info into separate .debug files, leaving the .so/binary files small for easy copying (e.g. to remote devices) but still leaving the possibility of debugging. Creating the .debug files is straightforward: given f=somelib.so: objcopy --only-keep-debug $f $f.debug strip $f objcopy --add-gnu-debuglink $f.debug $f This could maybe be done as a post-link step for shared libs and binaries.

I actually did this in bug 420474, but didn't turn it on. We need to change this line: http://lxr.mozilla.org/mozilla/source/Makefile.in#166 to add -c to MAKE_SYM_STORE_ARGS. Then, if you |make buildsymbols| in your objdir after building, the debug files will be split off (and packaged with the Breakpad symbols). |make package| has always stripped the binaries, so you can then use those symbols in conjunction with the packaged binaries.

ted: what's our modern story for this? If we're not doing this, it feels like something that could benefit mobile development.

Nothing has really changed. It would be a lot simpler to implement this on top of bug 1337986, since we already have the "strip + add debuglink" code in the symbol dumping step, and it's possible to run that as part of the build now. That being said, I'm not sure this is fully relevant given that our only real supported mobile platform is Android now, and running on Android requires packaging to generate an apk, so the binaries that get loaded on-device are always stripped. I haven't tried debugging an Android build in a long time though, so I'm not sure if the workflow there is good or not. CCing a few people that should know.

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #3) > Nothing has really changed. It would be a lot simpler to implement this on > top of bug 1337986, since we already have the "strip + add debuglink" code > in the symbol dumping step, and it's possible to run that as part of the > build now. That being said, I'm not sure this is fully relevant given that > our only real supported mobile platform is Android now, and running on > Android requires packaging to generate an apk, so the binaries that get > loaded on-device are always stripped. I haven't tried debugging an Android > build in a long time though, so I'm not sure if the workflow there is good > or not. The workflow is pretty odd, but it's built into jimdb (https://wiki.mozilla.org/Mobile/Fennec/Android/GDB) and has a bunch of library related tweaks to make everything work. I doubt this has big value for Fennec platform engineers, but I'll NI snorp and jchen for their comment.

Yeah, Fennec already strips the libs in the APK and then JimDB uses the unstripped libs from the objdir to resolve symbols during debugging. One thing that would be interesting is if we publish .debug files with Nightly builds, and then you could download the appropriate set to debug that. I guess we already publish the objdir, though?

We don't publish the objdir, but we do upload debug symbols to the symbol server. Are our Nightly builds built as debuggable though?

Yes the Nightly APKs are debuggable

One can get the debug symbols from symbols.mozilla.org. In fact, iirc, fetch_symbols.py works on Android builds (as long as you unpack the apk first)... well, at least it used to work before the libraries were compressed with 7z or szip.