Eric Seidel a7a3147fd4 Fix skydb --gdb to always have symbols
This replaces my previous --gdb work:
https://codereview.chromium.org/848013004/

And obsoletes my build-id based attempt:
https://codereview.chromium.org/788903011

Context:
mojo_shell downloads arbitrary binaries from
urls copying them to temp files before calling
dlopen.  Because the names it used were random
this broke gdb, pprof, etc. tools which wanted
to make address -> symbol translations based
on the library load path.

The major thing this change does is move away
from the previous method of watching the logs
of mojo_shell for 'Caching %url as %file...'
messages or the /tmp/mojo_shell.%pid.map
file to having mojo_shell use a priori knowable
names for all of its library loads.  Thus
we can similarly build a directory of correctly
named symboled binaries corresponding to the
expected load names of libraries.

This change does this in 3 pieces:

1.  Introduces the concept of 'app ids' (which
are currently just the md5 of the distributed app
binary) and teaches dynamic_application_loader to
rename all apps to APP_ID.mojo before loading them.
This has the nice side-effect of always loading
an app with a dlopen/library name which is both
unique to the application as well as predictable.

2.  Re-writes the mojo_cache_linker script to
no longer watch stdin/adb logcat for 'caching...'
messages and instead build a links directory
based on pre-determined app_ids (md5s) linking
back to the symboled binaries.

3.  Remove a bunch of the former mojo_cache_linker
calling code which is no longer needed now that
the library_names of loaded application .so's are
predictable before launching mojo_shell

I'm happy to make app_ids fancier, originally I
was going to use ELF's build-id's directly:
https://codereview.chromium.org/788903011
but unfortunately gdbserver does not know
how to do a build-id lookup on the serverside:
https://groups.google.com/a/google.com/forum/#!topic/gdb-discuss/Fd0R-gFaqXk

R=aa@chromium.org, abarth@chromium.org

Review URL: https://codereview.chromium.org/866383004
2015-01-23 15:18:21 -08:00
Description
A vendored version of the flutter engine for firka :3
323 MiB
Languages
Dart 75.4%
C++ 16.4%
Objective-C++ 2.7%
Java 2.7%
Objective-C 0.6%
Other 1.8%