In order for pprof to find the symbols in the profile, we need to rename the
binaries from foo.mojo to libfoo_library.so. This CL adds that step to the
stop_profiling command in skydb.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/812573006
Previously, the trace coordinator would try to write a trace to the file
system, but it is awkward to write to the file system on Android. Instead, we
now stream the trace data to a data pipe. The Sky debugger consumes that data
pipe and sends it to the host via the command HTTP server.
R=eseidel@chromium.org, jamesr@chromium.org
Review URL: https://codereview.chromium.org/853943005
I changed skydb start to take a build directory
and read the configuration out of gn args instead
of --release, --debug, etc. This should be more
flexable and handle all the crazy asan cases
mopy/config.py tries to. Once we merge sky/tools
into mojo/tools we should make mopy/config use this
method too.
This follows similar patterns to what
mojo/tools/android_mojo_shell.py does, but doesn't
use as much of the (old) android_commands and forwarder
logic. We could even remove all of that
build/android/pylib code by calling the (new)
adb reverse instead of using Forwarder (in a later patch).
This still only supports a single skydb running
at once, but it should be trivial to move the
skydb.pids file into the build directory or to have
it support more than one instance. The big question
there is what the command-line usage should look like
when supporting more than one running instance. See
the mojo-dev thread on the subject.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/816693006
This makes skydb pass a command_port to prompt.cc
as a commandline argument. I removed passing of the
url and instead pass the url via a separate /load command.
This has the nice side effect of guarenteeing that
the sky instance is up and ready to respond to commands
when skydb exits. It also prepares us for running
more than one copy of prompt.cc as jamesr requested
for both Release and Debug or for on both your android
device as well as your local machine.
R=abarth@chromium.org, jamesr@chromium.org
BUG=
Review URL: https://codereview.chromium.org/841113003
This makes it much easier to work with a device where we
don't expect a persistent commandline session. Prompt no longer
actually makes a prompt but rather just runs an http server.
This is just a v1 patch. It doesn't work with android yet
and it isn't smart enough to allow you to run more than one
copy of prompt.cc at the same time (since you can't control
the port it listens on). If you have a second copy of
prompt runnning (or anything else bound to port 7777) it will
just crash.
We could make this a lot better, including splitting out the
pid-file tracking for sky_server into sky_server instead of
having skydb manage it.
R=ojan@chromium.org, abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/840973002
Since we don't support using the component build to produce mojo apps,
we can simplify the build targets in a few ways:
*) every mojo_native_application must depend on the c system thunks,
so just make that part of the template instead of requiring the dep
*) there's no such thing as depending on gles2 headers from a component,
so delete the forwarding group.
Most targets that want to use the gles2 headers in a mojo context
want to depend on an implementation through the thunks, so
//mojo/public/c/gles2 does just that. A smaller number of targets (such
as the implementation of the thunks) want to just depend on the headers
but not an impl, so they can depend on //mojo/public/c/gles2:headers.
The //mojo/public/gles target isn't that useful since the only thing we
expose is a set of C entry points.
We can probably also simplify the c system targets, but that's trickier
due to more extensive use from the chromium side.
BUG=438701
R=viettrungluu@chromium.org
Review URL: https://codereview.chromium.org/780733002
This adds a tracing service that can aggregate tracing data from
multiple sources and write a json file out to disk that trace-viewer can
understand. This also teaches the shell, sky_viewer, and various other
services how to register themselves with the tracing service and provide
tracing data on demand. Finally, this teaches the skydb prompt to tell
the tracing service to start/stop tracing when the 'trace' command is
issued.
The tracing service exposes two APIs, a collector interface and a
coordinator interface. The collector interface allows different entities
to register themselves as being capable of producing tracing data. The
coordinator interface allows asking the service to collect data from
all registered sources and flushing the collected data to disk.
The service keeps track of all open connections to registered sources
and broadcasts a request for data whenever the coordinator's Start
method is called, then aggregates all data send back into a single
trace file. In this patch, the tracing service simply gives all sources
1 second to return data then flushes to disk. Ideally it would keep
track of how many requests it sent out and give each source a certain
amount of time to respond but this is simple and works for most cases.
The tracing service can talk to any source that is capable of producing
data that the trace-viewer can handle, which is a broad set, but in
practice many programs will want to use //base/debug's tracing to
produce trace data. This adds code at //mojo/common:tracing_impl that
registers a collector hooked up to //base/debug's tracing system. This
can be dropped in to the mojo::ApplicationDelegate::Initialize()
implementation for most services and applications to easily enable
base tracing. Programs that don't use //base, or that want to register
additional data sources that can talk to trace viewer (perhaps providing
data that's more easily available from another thread, say) may want
to create additional connections to the tracing service.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/769963004
This moves the tracing code and mojoms from sky/viewer/services/ to
mojo/common/ in anticipation of refactoring these to be more widely
usable. This doesn't actually change behaviors yet.
BUG=436639
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/751303003
This teaches the SkyDebugger prompt how to tell
the sky debugger (server) to shut down instead of
just calling exit(0).
This also teaches the WindowManagerApp (server) how
to tear down all of its connections itself instead
of depending on the pipes to do so (which would
crash when youd delete the WindowManagerApp as the
pipes could outlive it with WindowManagerImpl objects
containing raw pointers back to the WindowManagerApp).
Shutdown is not yet clean. It errors out trying to
talk to the X11 server, but it's closer to clean
than it was prior to this change. I may add back
and exit(0) to side-step shutdown until it can be
made fully clean.
R=jamesr@chromium.org, sky@chromium.org
BUG=430291, 430242
Review URL: https://codereview.chromium.org/695183003
I had to also register for the text/plain mime-type
which turned out to be harder than expected.
Mostly due to my confusion with mojo_shell
using last-argument-wins argument parsing.
R=ianh@google.com
Review URL: https://codereview.chromium.org/672363002
