llvm dev - Oct 2015 - RFC: Move parts of llvm-symbolizer tool implementation to LLVMSymbolize library

Hi,

We have a lot of non-trivial logic accumulated in the
implementation of llvm-symbolizer tool
(tools/llvm-symbolizer/LLVMSymbolize.{h,cpp}), for instance:

* dynamic dispatch between DWARF and PDB debug info;
* building address->symbol_name mapping from object file (with special
cases for PowerPC function descriptor section, and COFF export tables);
* finding debug info stored in separate files (.dSYM files on Darwin, ELF
.gnu_debuglink section, etc.);
* demangling (with platform-specific implementations for Windows and Unix).

I propose to move this code into a separate library LLVMSymbolize (stored
under lib/DebugInfo/Symbolize), and make llvm-symbolizer a short and simple
tool using it. This would allow to:

* implement in-process symbolized stack trace printers (for the cases when
it's possible to link in a bunch of LLVM libraries into the executable).
* easily write more tools that can make use of symbolized code locations,
such as coverage data visualizers.
* (at least sometimes) write unit tests instead of testing functionality by
running "llvm-symbolizer" executable on pre-built executables checked
in
repository.

Any comments/objections?

-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151020/3d8655a0/attachment.html>

I would say it is worth it if someone is actually planning on using
the library in something else.

Moving the code "just in case" or to create unit tests is not a good
reason IMHO.

On 20 October 2015 at 16:54, Alexey Samsonov <vonosmas at gmail.com>
wrote:
> Hi,
>
> We have a lot of non-trivial logic accumulated in the
> implementation of llvm-symbolizer tool
> (tools/llvm-symbolizer/LLVMSymbolize.{h,cpp}), for instance:
>
> * dynamic dispatch between DWARF and PDB debug info;
> * building address->symbol_name mapping from object file (with special
cases
> for PowerPC function descriptor section, and COFF export tables);
> * finding debug info stored in separate files (.dSYM files on Darwin, ELF
> .gnu_debuglink section, etc.);
> * demangling (with platform-specific implementations for Windows and Unix).
>
> I propose to move this code into a separate library LLVMSymbolize (stored
> under lib/DebugInfo/Symbolize), and make llvm-symbolizer a short and simple
> tool using it. This would allow to:
>
> * implement in-process symbolized stack trace printers (for the cases when
> it's possible to link in a bunch of LLVM libraries into the
executable).
> * easily write more tools that can make use of symbolized code locations,
> such as coverage data visualizers.
> * (at least sometimes) write unit tests instead of testing functionality by
> running "llvm-symbolizer" executable on pre-built executables
checked in
> repository.
>
> Any comments/objections?
>
> --
> Alexey Samsonov
> vonosmas at gmail.com

To create unit tests is a pretty good reason IMO :)

That said, I'd be a fan of trying to encapsulate all of this behind an
interface. I like that most of the tools are exceptionally light weight and
it makes it much more obvious what's "wrapper" versus
"functionality" in
something like llvm-symbolize. That said, I'll be interested to see the
library design :)

-eric

On Wed, Oct 21, 2015 at 7:35 AM Rafael Espíndola <llvm-dev at
lists.llvm.org>
wrote:
> I would say it is worth it if someone is actually planning on using
> the library in something else.
>
> Moving the code "just in case" or to create unit tests is not a
good
> reason IMHO.
>
> On 20 October 2015 at 16:54, Alexey Samsonov <vonosmas at gmail.com>
wrote:
> > Hi,
> >
> > We have a lot of non-trivial logic accumulated in the
> > implementation of llvm-symbolizer tool
> > (tools/llvm-symbolizer/LLVMSymbolize.{h,cpp}), for instance:
> >
> > * dynamic dispatch between DWARF and PDB debug info;
> > * building address->symbol_name mapping from object file (with
special
> cases
> > for PowerPC function descriptor section, and COFF export tables);
> > * finding debug info stored in separate files (.dSYM files on Darwin,
ELF
> > .gnu_debuglink section, etc.);
> > * demangling (with platform-specific implementations for Windows and
> Unix).
> >
> > I propose to move this code into a separate library LLVMSymbolize
(stored
> > under lib/DebugInfo/Symbolize), and make llvm-symbolizer a short and
> simple
> > tool using it. This would allow to:
> >
> > * implement in-process symbolized stack trace printers (for the cases
> when
> > it's possible to link in a bunch of LLVM libraries into the
executable).
> > * easily write more tools that can make use of symbolized code
locations,
> > such as coverage data visualizers.
> > * (at least sometimes) write unit tests instead of testing
functionality
> by
> > running "llvm-symbolizer" executable on pre-built
executables checked in
> > repository.
> >
> > Any comments/objections?
> >
> > --
> > Alexey Samsonov
> > vonosmas at gmail.com
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20151021/04a1294c/attachment.html>