examples/addr2line: flush stdout after each response

[anakryiko]

Forcefully flush stdout after each address is handled. This allows to use
addr2line in a "coprocess" mode, in which another process forks/execs
addr2line, establishes two uni-directional pipes for passing input addresses
and reading back responses, and uses addr2line in a client/server fashion.
This is done for amortizing start up costs and make stack symbolization as
cheap as possible.

The problem with the above "coprocess" mode is that because addr2line is
getting Unix pipes for stdin/stdout, std::io::stdin()/std::io::stdout() will
switch to fully buffered mode, instead of line-buffered one that happens when
stdin/stdout is wired to interactive shell. Because of that buffering, driving
application will never get response (unless it's bigger than internal buffer,
which is quite big, though I don't know exactly how big), because it will
never be actually flushed into the pipe. This problem generically is solved
through a complicated dance with setting up pseudo-terminal, creating new
session, etc, etc. It's complicated enough to discourage such use completely.

But if we can modify addr2line to enforce flushing data after each response,
then all this problem goes away, because buffering doesn't matter much
anymore. It shouldn't hurt performance noticeably at all.

Signed-off-by: Andrii Nakryiko andrii@kernel.org

[philipc]

Thanks!

Note that currently this code is intentionally placed in examples/ rather than src/bin/, and it is not a mature replacement for the addr2line from binutils or llvm.

[anakryiko]

Note that currently this code is intentionally placed in examples/ rather than src/bin/, and it is not a mature replacement for the addr2line from binutils or llvm.

Yeah, I realize that. But it seems to be working very well for kernel stack trace symbolization. I'm using it in my proof-of-concept tool at https://github.com/anakryiko/retsnoop, and it's surprisingly fast and reliable. So thanks a lot for adding that examples/addr2line part!