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

James Henderson via llvm-commits llvm-commits at lists.llvm.org
Mon May 20 00:29:19 PDT 2024


https://github.com/jh7370 commented:

Honetly, I feel like the requested "check that llvm-symbolizer is responding to input by sending it an arbitrary string" is a bit of a hack too: what if llvm-symbolizer were to crash immediately after printing its response? I don't have any great alternative suggestions that meet the use-case though, so I'm willing to let this in, unless any other ideas appear better.

Some alternatives for potential discussion, which may or may not be better:

1. Have llvm-symbolizer print something to stdout immediately before starting its waiting for input loop. In this case, the launching process could monitor llvm-symbolizer's stdout via a pipe or similar and when the relevant output has been received, it can assume it is safe to start sending input. We could put this additional output under a switch, so that the tool isn't spouting unnecessary output under other usage.
2. Have a "magic" input string that when received causes llvm-symbolizer to print a specific output string to indicate it is ready. I'm not necessarily in favour of this ("magic" stuff , but I could see it being the start of a potential full interpreter functionality, where llvm-symbolizer receives various non-address inputs and performs certain operations on receipt (this could be useful to change output options mid-run, for example).
3. Frame challenge: the use case is invalid as a good response doesn't mean that more responses will come from llvm-symbolizer (see above re. crash after a response for one possible example). Instead, the process communicating with llvm-symbolizer should just assume that the process is able to receive input unless its stdout pipe is closed or the process is no longer alive. (To be clear, I'm not saying this challenge is correct, but I want to make sure we're not adding edge case behaviour changes to handle a use case that isn't actually necessary or reliable, so it's more about provoking thoughts on the issue).

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


More information about the llvm-commits mailing list