This flag to mojo_shell is gaining the ability to produce tracing info
starting very early in process startup. This allows the skydb 'start'
command to pass this command through to mojo_shell.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1065723003
Until now, we were saving downloaded file to the temporary directory
with a name being the hash of the file content. It means there is a race
when the same content is downloaded from 2 different URLs.
To fix this, we now create an intermediary directory that is the hash of
the URL.
Also, because this is only needed for debugging with gdb, and this is
inefficient in term of both CPU and storage (we do not know when to
delete the temporary directory), we control this with a command line
flag.
R=ncbray@chromium.org, eseidel@chromium.org
BUG=https://github.com/domokit/mojo/issues/61
Review URL: https://codereview.chromium.org/1011333003
Before this change Sky would hit 404s when trying to
load examples from domokit.github.io.
I also added a separate sky_home and updated the default
url to point to sky_home instead of home.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1016143002
Dart actually expects package: to work. This CL makes package:foo
map to /packages/foo, similar to how Dartium or bin/dart would expect.
This also means overlaying the /gen directory over the actual package
outputs (as consumers of an SDK would expect) as well as adding
an additional /lib indirection for the actual package source as
the Dart pub tool will expect.
This is far from perfect, but it unlocks us actually producing a
sky SDK.
I expect there may be some fallout from this change as I'm sure I
missed some package: uses. We also don't have a general solution
for all /foo/bar/baz includes which randomly included parts
of mojo's source directory. Those will need to be updated to use
a package: and deploy_sdk.py taught how to build a package for them.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/990493002
- New chromium clang rules require explicit external destructors so
system/lib added for MessagePipe, DataPipe and SharedBuffer
- New chromium clang rules require override and no virtual in
declarations, so many files updated.
- cc_strip_video patch updated.
BUG=
R=jamesr@chromium.org
Review URL: https://codereview.chromium.org/988693005
This is basically skydb v2, except only for android.
I revisited some of the architecture decisions I made
in writing skydb. I also separated skyserver.py from
dependency on skypy/paths.py since it wasn't really adding
any value.
We could make this way fancier, but this should at least
make working with SkyDemo.apk easier for now.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/960233007
This patch allows to specify a full NetAddress on which the server is to
be set up.
This is needed to decide between running the server on externally
visible address (like http_handler would like) and localhost (like skydb
would like).
No change in behavior of existing clients in the Mojo repo should occur.
A follow-up patch will switch some of the clients from 0.0.0.0 to
localhost.
BUG=460908
R=qsr@chromium.org
Review URL: https://codereview.chromium.org/953513002
This switches to using StrongBinding<>s in sky's ContentHandlerImpl
and TestHarnessImpl implementations.
These are the last uses of the deprecated InterfaceImpl<> helper in
the mojo repo (more uses exist in other repos).
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/934403002
Unfortunately, using --origin on Linux is slow and too painful to use at the
moment. We should work on fixing that, but currently many of us have this in
our local working copy anyway.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/922823002
The tracing service logically provides one service, TraceCoordinator, which can
start and stop tracing sessions. It also can connect to any number of
TraceControllers each of which can supply tracing information on demand.
Whenever an app connects to the tracing service, the tracing service attempts to
connect to that app's TraceController interface. If the app provides this
interface then tracing data will be requested whenever tracing starts. If the
app doesn't, then the pipe just closes. Thus apps that want to be traced can do
so by creating however many connections to the tracing service they want and
registering a TraceController implementation on each outgoing connection.
The shell connects in a similar fashion by connecting to the tracing service and
providing a TraceController implementation. The code looks a bit different since
the shell is special.
BUG=451319
R=viettrungluu@chromium.org
Review URL: https://codereview.chromium.org/791493006
Before we start adding more uses of mojo app ids we should use
to a non-broken hash function. :)
What was holding me back before was I wasn't aware of us having an
incremental hash api other than base/md5.h (others in base only operate
on the full input data), however it turns out that the crypto/ library
has one in crypto/secure_hash.h.
R=abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/868253006
Already other applications use sky's simple window
manager (mojo:sky_debugger) as a full-screen window
manager. This moves this to /services and removes
all sky references from it.
As a part of this I've removed inspector support
from skydb. It was already broken and will need
to be re-thought to not involve calls into
this new window manager.
I'm also flipping the relationship between prompt.cc
and debugger.cc for skydb. Skydb will tell mojo_shell
to start sky_debugger_prompt instead of sky_debugger.
I'm also renaming sky_debugger_prompt to be
sky_debugger.
R=abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/883983004
This CL simplifies the sky_server to only map the build directory into /gen,
which will make the deploy script simpler. This CL updates all the imports to
use the /gen prefix when referring to generated files.
TBR=eseidel@chromium.org
Review URL: https://codereview.chromium.org/881093003
I also fixed skydb to use --args-for sky_debugger to
automatically issue the load from 'start' even when
the --gdb option is present.
I tried to invoke gdb_attach directly from within start_command
but that seemed to cause some strangeness with my zsh shell
where it would automatically suspend gdb. So I'll revisit
that change in the next patch.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/880143002
sky_debugger will load the default url in every view that it's
asked to embed. Think of the default_url as being like the
home-page in a conventional browser.
I also fixed prompt.cc to not terminate the entire mojo
environment when it can't start itself, but rather just
quit its own application.
With this patch I'm able to hack up mojo_shell to be able
to have a sensible default behavior when clicked from
the Android homescreen, but I'll land those hacks in a
separate change.
TBR=abarth@chromium.org
BUG=451620
Review URL: https://codereview.chromium.org/875183002
Many of the .so files in out/Debug are hundreds
of megabytes in size. md5sum can take seconds
to churn through them all, so I've added
a small caching layer which makes this script
take no time in the common case.
R=abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/865463004
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-gFaqXkR=aa@chromium.org, abarth@chromium.org
Review URL: https://codereview.chromium.org/866383004
