
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
Description
A vendored version of the flutter engine for firka :3
Languages
Dart
75.4%
C++
16.4%
Objective-C++
2.7%
Java
2.7%
Objective-C
0.6%
Other
1.8%