Feature requests: list of PIDS, and all threads

[George Spelvin]

>> 1) Some way to supply a *list* of pids to be traced, without having to
>>     prefix each with "-p".  This would make it much easier to paste
>>     in the output of "pgrep" or the like.
>>
>>     Two options come to mind:
>>     -P means "all bare arguments are pids"; the case of mixing
>>        pids and a commnd line process is somewhat uncommon.
>>     -p takes a whitespace-separated list of pids.  So I could
>>        use -p "`pgrep foo`".

> I guess we can support -p PID1,PID2 _and_ -p "PID1 PID2".
> Why not?

That did seem simplest BUT be sure to accept other whitespace, and in
particular \n, if you're not relying on the shell to break the list
into argv[].

echo "`pgrep xterm`" | xxd
0000000: 3330 3736 0a33 3038 390a 3931 3933 0a39  3076.3089.9193.9
0000010: 3636 350a 3232 3031 340a 3232 3033 320a  665.22014.22032.
0000020: 3235 3530 320a 3235 3531 340a            25502.25514.

>> 2) A simple way to trace all threads of a process.  strace doesn't really
>>     take process IDs but thread IDs, so if a process has multiple threads,
>>     only the primary process gets traced.  I'd like an easy way to say
>>     "what the heck is firefox doing?" and get all the threads.
>>     (Once again, this is working around a limitation of pgrep.)

> The code to do so is there (-p PID -f would do what you want even today -
> but it will also follow forks which you didn't ask for).

Oh!  Actually, that's mostly what I'm interested in; I just didn't
know that worked!

I thought I had tried it once and had it not work, but either my memory
is faulty or strace improved, bexause you're absolutely right!

> We only need an option to indicate this. -T and -t are taken. -P is taken too.
> We are running out of alphabet! :)

Given the above, what might be more useful is a "drop thread on exec" option,
so I'm tracing a single multi-threaded program, and not what it execs.
That might factor into your choice of letters.

>> 3) A third thing that would be really nice would be a "don't break system
>>     calls" option.  Basically, if one system call is pending when a second
>>     happens, DON'T display<pending...>  unless a reasonable timeout has
>>     elapsed; rather just defer printing anything for the first system
>>     call until it returns, when it can be printed on one line.

> Uhhuh. That would not be so easy to implement. And some people
> do want to know exact moment syscalls were entered/exited.

Well, it definitely needs to be an OPTION.  That said, I definitely
understand that it would be a pretty major internal change.

> -tt -ff does almost what you want. It separates logs one output file
> per pid. A script can be written to combine them into one file,
> using timestamps for ordering. Would this satisfy you?

Indeed.  It would come even closer if there were an option to break
system calls into <unfinished ...> and <... resumed> lines if the time
between them exceeded a threshold.

I still think it wouldn't be THAT hard; the main change would be some
code to buffer the trace output rather than printing it immediately.
GNU libc has support for that natively, but it would have to be something
portable to all the systems that strace runs on.

But anyway, thanks for the response!