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

[Serge Pavlov via llvm-commits]

spavloff wrote:

> A good response means that the client program found the llvm-symbolizer executable and it reached its main loop, which is a useful thing to know on its own regardless of whether later requests fail. A bad response is a strong signal (not a guarantee) that there was a user error and the client program should tell the user to e.g. check their $PATH.

This is already implemented in llvm-symbolizer. The client can send empty line to it and get expected result `??:0\n`. The only issue, as I understand, is that stderr also has some output. 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. This patch tries to make life easier by treating empty input string in a special way, reacting without anything on stderr. What is wrong with such solution?

> > What does binutils addr2line do in this case?
>
> Looks like it prints ??:0\n without any output to stderr. We might want to emulate that in the addr2line emulation mode but since llvm-symbolizer has historically responded to \n with \n I reckon that's what llvm-symbolizer should do by default.

Echoing is in the past. We can implement it for empty string, but we should think twice. 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/pull/92660