llvm dev - Feb 2019 - [llvm-symbolizer] Add an alias to be a drop-in replacement for addr2line

Hello everyone,

The latest efforts made "llvm-symbolizer" to behave very close to
GNU's "addr2line" tool.
However, there are still some differences, which prevent it to be a drop-in
replacement.
In particular:

* "llvm-symbolizer" has "-I", "-f" and
"-C" options ON by default;

* "llvm-symbolizer" prints line and position while
"addr2line" prints only a line.

* "addr2line" allows more flexible usage of the "-e" option.
  For example, "-fe <file>" and "-e<file>"
command lines are handled smoothly.

We probably should not change the behavior of the existing tool, which might
affect,
for example, parsers of its output. But what if we create another tool, say,
"llvm-addr2line",
in the same way as "llvm-readelf" co-exists with
"llvm-readobj"? That tool might
follow the behavior of "addr2line" better without risking to break
compatibility
for current users of "llvm-symbolizer".

What do you think?

Best Regards,
Igor Kudrin
C++ Developer, Access Softek, Inc.​

Sounds reasonable to me, and was also suggested on a recent review:
https://reviews.llvm.org/D57083#1368695 (+cc reviewers there)

On Tue, Feb 19, 2019 at 4:15 AM Igor Kudrin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello everyone,
>
> The latest efforts made "llvm-symbolizer" to behave very close to
GNU's
> "addr2line" tool.
> However, there are still some differences, which prevent it to be a
> drop-in replacement.
> In particular:
>
> * "llvm-symbolizer" has "-I", "-f" and
"-C" options ON by default;
>
> * "llvm-symbolizer" prints line and position while
"addr2line" prints only
> a line.
>
> * "addr2line" allows more flexible usage of the "-e"
option.
>   For example, "-fe <file>" and "-e<file>"
command lines are handled
> smoothly.
>
> We probably should not change the behavior of the existing tool, which
> might affect,
> for example, parsers of its output. But what if we create another tool,
> say, "llvm-addr2line",
> in the same way as "llvm-readelf" co-exists with
"llvm-readobj"? That tool
> might
> follow the behavior of "addr2line" better without risking to
break
> compatibility
> for current users of "llvm-symbolizer".
>
> What do you think?
>
> Best Regards,
> Igor Kudrin
> C++ Developer, Access Softek, Inc.​
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190219/09c31b99/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190219/09c31b99/attachment.bin>

The alias sounds good.

I think there has been a lot of scope creep in the various LLVM binary
utilities. Originally, they were just knock-off, single-purpose, useful
programs, but now users want command line compatibility and format-string
compatible output. I don't have any strong objections against being more
drop-in compatible, but I do want to point out that this is revisiting some
pretty early design decisions, so it's not necessarily going to be easy.

Good luck! :)

On Tue, Feb 19, 2019 at 4:15 AM Igor Kudrin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello everyone,
>
> The latest efforts made "llvm-symbolizer" to behave very close to
GNU's
> "addr2line" tool.
> However, there are still some differences, which prevent it to be a
> drop-in replacement.
> In particular:
>
> * "llvm-symbolizer" has "-I", "-f" and
"-C" options ON by default;
>
> * "llvm-symbolizer" prints line and position while
"addr2line" prints only
> a line.
>
> * "addr2line" allows more flexible usage of the "-e"
option.
>   For example, "-fe <file>" and "-e<file>"
command lines are handled
> smoothly.
>
> We probably should not change the behavior of the existing tool, which
> might affect,
> for example, parsers of its output. But what if we create another tool,
> say, "llvm-addr2line",
> in the same way as "llvm-readelf" co-exists with
"llvm-readobj"? That tool
> might
> follow the behavior of "addr2line" better without risking to
break
> compatibility
> for current users of "llvm-symbolizer".
>
> What do you think?
>
> Best Regards,
> Igor Kudrin
> C++ Developer, Access Softek, Inc.​
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190219/c72d9c68/attachment-0001.html>