On Sat, Oct 17, 2015 at 2:10 PM, Rob Landley <[email protected]> wrote: > On 10/17/2015 01:38 PM, enh wrote: >> fwiw, android has never cared much about the 80 column limit. we'll >> show up to 1024 characters of /proc/pid/cmdline: >> >> USER PID PPID VSIZE RSS WCHAN PC NAME >> enh 18223 4219 902252 142880 futex_wait 7f67f08177ce S >> /opt/google/chrome/chrome > > I'm fetching 2048 chars (half of toybuf) but only displaying that if > it's the last column and the truncate to screen width option is disabled > with -w (which isn't implemented yet but I'm probably just having _one_ > -w for unlimited rather than this -ww repeating nonsense from procps).
(yeah, our 1024 limit was just the size of the buffer that happened to be lying around.) >> our PC column was truncated on LP64 for a long time before anyone noticed. > > Ok, you've got "pc" for what I'm calling "addr". Hmmm. (I can certainly > add it as an alias. And I _am_ truncating... to 12 chars. Although I've > already implemented the "explicit width control" logic from the man page > ala "ps -o pc:16" (and yes, you can use = and : on the same entry > although : has to go first). i didn't mean to imply we care about the name (especially because we don't have -o), just that this is a sometimes useful field. > While I do want to grab the column auto-adjust logic from vmstat.c > (which is _not_ the same auto-adjust logic as ls -l, in vmstat it steals > unused spaces from adjacent columns, in ls it precomputes all the > columns to measure them), neither really quite matches the ability to > explicitly specify column sizes. > > I'm vaguely planning to grab the vmstat approach (_after_ otherwise > finishing and promoting this sucker), treating the specified sizes as > "pad out to", and then letting _only_ the numeric fields (and maybe > wchan) expand because usernames and cmdline can be pathologically long > if you don't truncate them. > > The rightmost column already expands out to screen size (or to unlimited > with -w... why don't I implement -w now while I'm thinking about it...). > > And come to think of it, the default shouldn't be 80. If you haven't got > a tty, behave like -w (INT_MAX). > >> our default columns are unusual too (the above output is the default). >> (PC is the kernel's "kstkeip".) > > Um, do you mean entry #29 "EIP" from /proc/$PID/stat? yeah, for some reason we used the name of the kernel macro to pull the pc from task_struct. > I see you're also printing it in hex. All the other fields are decimal > (except the one that's specified as _octal_ by posix), but decimal is > just too many digits here (and not what anybody's going to be comparing > /proc/$PID/maps and objdump -d output against if they really need to > dissect a running process without gdb. And yes, I have done that. yeah, since that's the only use for this field, only hex makes sense. >> we also had numeric wchan output for years and no-one complained. in >> fact, it wasn't until i got a patch to increase the width for the >> numeric output for LP64 (!) that it annoyed me enough to fix it. > > I'm already reading the proc/$PID/wchan data for that field. I was > considering having addr be the numeric wchan (posix doesn't _say_) but > it's zero a lot and EIP should never be, so... more useful. it's actually 0 a lot. the kernel uses 0 to mean "none of your business". all kernel threads show up as 0 too, even if you're root. > Rob -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
