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

James Henderson via llvm-commits llvm-commits at lists.llvm.org
Fri May 24 00:13:09 PDT 2024


jh7370 wrote:

> > "ECHO\n" looks good to me (compatible with pre [1792852](https://github.com/llvm/llvm-project/commit/1792852f86dc75efa1f44d46b1a0daf386d64afa) output). `ECHO` can also be used as command line arguments, e.g.
> > ```
> > llvm-symbolizer 'DATA 0x2' 'ECHO' 'DATA 0x2' --obj=a.o
> > ```
> 
> If llvm-symbolizer reads input and sees "ECHO", it could be a command `ECHO` or a global symbol named `ECHO`. Commands `CODE`, `DATA` and `FRAME` all have an argument separated by a space. This space allows us to distinguish a command from a symbol. It the case of `ECHO`, there is no such possibility,

That's a minor pain, but I think we can work around this. How about this proposal:
1.  An argument of just 'ECHO' is treated as a symbol.
    1. As an optional extension, if possible and desired, we could have it treated as an ECHO command with no additional characters, if the symbol is not found, but I don't know how practical that would be to thread through the llvm-symbolizer architecture. 
2. To be treated as a command, the argument must have at least one additional space after the ECHO, e.g. this would result in a proper ECHO as desired: `llvm-symbolizer 'DATA 0x2' 'ECHO ' 'DATA 0x2'`.
3. The same applies when reading stdin, with the trailing end of line character(s) (i.e. including '\r\n' on Windows) NOT being treated as part of the ECHO line for this purpose. So a stdin entry of just `ECHO\n` would result in an attempt to look up the ECHO symbol - you'd need e.g. `ECHO \n` instead.
4. llvm-symbolizer implicitly adds a '\n' at the end of a thing that is echoed unconditionally.

This does have the limitation that it's impossible to simply echo a blank line. I don't have an idea for how to handle this, short of some sort of special character interpretation or similar, e.g. `ECHO,` being treated as an `ECHO` command with no additional content, similar to .bat files - I'm not a fan of this approach, so would prefer not to have it, if the alternative is acceptable.

Thoughts?

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


More information about the llvm-commits mailing list