[llvm] [symbolizer] Empty string is not an error (PR #92660)

[via llvm-commits]

pcc wrote:

> Alternatively suggestion 2 I think would satisfy this, though I'd prefer the input string to cause a response to be a little less magic, e.g. introduce a "ECHO" directive, a bit like we have CODE, DATA etc, and then it just prints everything else in the same input line.

If we were going to do something else, `ECHO\n` returning `ECHO\n` would work for me. It would also be backwards compatible with older versions of llvm-symbolizer.

> A client program could just ignore these data, or catch them to tell the user the problem. But for some reason it is not suitable.

I wouldn't say "just". Reading stdout while filtering out "harmless" errors from stderr makes the client program an order of magnitude more complex. For example, we now need to create a pipe for stderr and select on (stdout, stderr) every time we want to read something. It's also not necessarily clear when llvm-symbolizer has finished printing the error. For example, what if there are multiple errors or a single error over multiple lines, or what if llvm-symbolizer "succeeded" but printed a warning? Looks like there are already a couple of cases where llvm-symbolizer will print a warning. So the current interface is really only suitable for client programs that want to display any errors to the user (by not intercepting stderr). If we wanted to make things easier for client programs that want to do something else with errors, there should probably be a separate mode with one output stream that conveys both results and errors.

> Now interface of llvm-symbolizer is compatible with addr2line (where functionality intersects) and is consistent. The tool responds to any input and does it uniformly. If the input is something that cannot be mapped into source line, llvm-symbolizer outputs fixed string. If it starts printing something new in such case, some users(scripts) may be confused, somebody's software could be broken. If we decide to make such change, we should mention it in release notes and have solid justification for breaking compatibility. Why \n is suitable but ??:0\n is not?

https://github.com/llvm/llvm-project/commit/1792852f86dc75efa1f44d46b1a0daf386d64afa caused my llvm-symbolizer-utilizing program to break because it was sending `\n` and expecting `\n`. addr2line isn't the only piece of software that llvm-symbolizer should be compatible with. In its default mode (not the addr2line compatibliity mode), it should also aim to be compatible with older versions of itself. That being said, I happen to not care that much about breakage in my program for now (it is still under development, and it interacts with a specific version of llvm-symbolizer so I can update it to follow whatever protocol we decide), but all things being equal, matching the older behavior seems preferable.

https://github.com/llvm/llvm-project/pull/92660