distinguish debugging, testing, and profiling

[Google Code Exporter]

vogar's a lot more complicated than it was. there's a lot of infrastructure 
between you and the code you're running. for testing, this is fine, and 
actually advantageous: that infrastructure is doing useful stuff.

for debugging, it's a pain in the ass. it means you don't get to see all the 
output. it means it can be hard to isolate a failure because you can't avoid 
causing failures in the infrastructure. it makes it harder to attach gdb, use 
strace, use tcpdump, use valgrind. (all of which really ought to be vogar 
options, so there's never any excuse to not use the best tools for the job.)

for profiling, we do want infrastructure, but different to what we've currently 
got; we want something that ensures we're running from one big dex (for the 
benefit of dexopt).


i know that there are existing bugs for (a) getting native output and (b) 
helping dexopt, but this is the first time i've realized there's perhaps a 
three-way split rather than the two-way one we've talked about before, and the 
first time i've thought that maybe vogar should behave radically differently in 
the "debugging" case.

Original issue reported on code.google.com by [e-mail] on 16 Jul 2010 at 6:10

[Google Code Exporter]

How do you feel about a --setup-only mode? Vogar would run dx, copy files to 
the device, and then print the command you need to run yourself. You could 
taylor this command to your particular needs, similarly to what we currently do 
by combining --no-clean and --verbose.

Original comment by [e-mail] on 16 Jul 2010 at 6:20

[Google Code Exporter]

that's part of it, but i'd like to cut out as many code middlemen as possible. 
i don't want any code running that isn't absolutely necessary: no sockets or 
xml or whatever. the tools i have in mind tend to be verbose/awkward enough 
that i'm basically unable to cope with the distraction of all the 
infrastructure's activity.

you've seen how inconvenient valgrind is (and that's without getting fancy and 
supporting stuff like dropping into gdb), but strace is even worse (thanks to a 
deficiency in android's strace), and tcpdump will get all the results' traffic 
mixed in (though admittedly it's possible if i were more leet that i could 
write a filter to ignore that).

Original comment by [e-mail] on 16 Jul 2010 at 8:30

[Google Code Exporter]

If we move to a model where the target vogar code runs the action as a 
subprocess, it might resolve a lot of these concerns, since it won't mix other 
code into the action, and sometrying to debug can be told the command line to 
exec the subprocess for interactive replay of an action... which makes me think 
of having a web interface on the target monitor for having it rerun, change 
options, ... :)

Original comment by [e-mail] on 16 Jul 2010 at 8:47