On 05/09/2016 07:46 PM, enh wrote: > On Mon, May 9, 2016 at 5:28 PM, enh <[email protected]> wrote: >> On Mon, May 9, 2016 at 4:47 PM, Rob Landley <[email protected]> wrote: >>> >>> >>> On 05/06/2016 11:49 PM, enh wrote: >>>> On Fri, May 6, 2016 at 9:11 PM, Rob Landley <[email protected]> wrote: >>>>> On 05/06/2016 08:34 PM, enh wrote: >>>>>> On Fri, May 6, 2016 at 6:01 PM, Rob Landley <[email protected]> wrote: >>>>>>>> 1794 1806 u0_a11 20 0 0% S 1502820K 54016K fg Binder_1 >>>>>>>> com.android.onetimeinitializer >>>>>>>> 1794 1807 u0_a11 20 0 0% S 1502820K 54016K fg Binder_2 >>>>>>>> com.android.onetimeinitializer >>>>>>>> 1811 1811 u0_a24 20 0 0% S 1518092K 57752K bg >>>>>>>> ndroid.calendar com.android.calendar >>>>>>>> 1811 1816 u0_a24 29 9 0% S 1518092K 57752K bg Jit thread >>>>>>>> pool com.android.calendar >>>>>>> >>>>>>> Wordwrapping in the original? >>>>>> >>>>>> yeah, sorry. gmail hates long lines. >>>>> >>>>> Makes it hard to see what you're going for, but I _think_ I understand. >>>>> Your fields are padded to fixed starting points and "thread name" is >>>>> whitespaced out if this isn't a thread? >>>> >>>> well, i can use field:123 to deal with that, plus thread names are >>>> limited to 12 characters or so by the kernel anyway... >>>> >>>> my real problem is that i don't currently have a field that gives me >>>> the process name in -T/-H mode. >>> >>> Define "process name"? >>> >>> There are 6 right now: args, cmd, cmdline, comm, command, and name. >>> >>> COMM is stat[2], NAME is argv[0] minus the path, COMMAND is argv[0] with >>> the path. >>> >>> Those are the three variants of "process name", the rest show command >>> line arguments too: CMDLINE is the full unmodified command line. ARGS is >>> the full command line using NAME for argv[0] (I.E. minus the path to the >>> binary you're running, if any). And then CMD is this crazy posix thing >>> that's one of the others depending on your command line options. >> >> compare >> >> ./toybox ps -A -T -o pid,tid,comm,command >> >> with >> >> ps -A -T -o pid,tid,comm,command > > (since it's taken this long and you still don't see what i'm saying, i > guess i shouldn't assume you're seeing what i'm seeing... > > here's what i see for some random chrome processes with ps: > > 86993 86993 chrome /opt/google/chrome/chrome --type=renderer > --lang=e > 86993 86997 Chrome_ChildIOT /opt/google/chrome/chrome --type=renderer > --lang=e > 86993 86999 Compositor /opt/google/chrome/chrome --type=renderer > --lang=e > 86993 87000 CompositorTileW /opt/google/chrome/chrome --type=renderer > --lang=e > 86993 87001 CompositorTileW /opt/google/chrome/chrome --type=renderer > --lang=e > 86993 87002 CompositorTileW /opt/google/chrome/chrome --type=renderer > --lang=e > 86993 87003 CompositorTileW /opt/google/chrome/chrome --type=renderer > --lang=e > 86993 87004 handle-watcher- /opt/google/chrome/chrome --type=renderer > --lang=e > 86993 87005 HTMLParserThrea /opt/google/chrome/chrome --type=renderer > --lang=e > 86993 87008 ScriptStreamerT /opt/google/chrome/chrome --type=renderer > --lang=e > 86993 128020 WorkerPool/5655 /opt/google/chrome/chrome --type=renderer > --lang=e > > and then toybox (ignoring that toybox mangled the large tid for the > last thread): > > 86993 86993 chrome /opt/google/chrome/chrome (deleted) > 86993 86997 Chrome_ChildIOT [Chrome_ChildIOT] > 86993 86999 Compositor [Compositor] > 86993 87000 CompositorTileW [CompositorTileW] > 86993 87001 CompositorTileW [CompositorTileW] > 86993 87002 CompositorTileW [CompositorTileW] > 86993 87003 CompositorTileW [CompositorTileW] > 86993 87004 handle-watcher- [handle-watcher-] > 86993 87005 HTMLParserThrea [HTMLParserThrea] > 86993 87008 ScriptStreamerT [ScriptStreamerT] > 86993 12802 WorkerPool/5655 [WorkerPool/5655] > > )
Sorry, the distraction was actually that when I tried your test I had that darn "./ps -A doesn't show all processes, but a make clean fixes it" thing again and I snapshotted the generated/ directory and compared them and it makes NO sense. (I suspect I overwrite some generated files with a later build. I still don't have a reproduction sequence.) Attempting to diff the "objdump -d generated/obj/ps.o" output was... long and uninformative. Distracted me from the topic at hand a bit. 99% sure this is a build dependency issue and not a code issue though. It _is_ reliably fixed by "make clean", I just... ??? Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
