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

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>

We have out-of-tree implementation of llvm-symbolizer-as-a-library, and I
still hope to upstream it one day (unfortunately, its build process is
really complicated).

Mike can probably comment on his plans for using symbolization in
coverage-related tools.

On Wed, Oct 21, 2015 at 11:34 AM, Eric Christopher <echristo at gmail.com>
wrote:
> 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 :)
>
Do you suggest to design it upfront, or you're fine with moving the
existing code first, and gradually updating the interface afterwards?

>
> -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
>>
>

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

On Wed, Oct 21, 2015 at 12:17 PM Alexey Samsonov <vonosmas at gmail.com>
wrote:
> We have out-of-tree implementation of llvm-symbolizer-as-a-library, and I
> still hope to upstream it one day (unfortunately, its build process is
> really complicated).
>
> Mike can probably comment on his plans for using symbolization in
> coverage-related tools.
>
> On Wed, Oct 21, 2015 at 11:34 AM, Eric Christopher <echristo at
gmail.com>
> wrote:
>
>> 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 :)
>>
>
> Do you suggest to design it upfront, or you're fine with moving the
> existing code first, and gradually updating the interface afterwards?
>
Don't know, what's the interface look like now? :) Were you just going
to
copy the LLVMSymbolize.[cpp,h] into the directory? That should be fine I
guess. I'd like to see the general ownership of objects separated out
fairly explicitly from the rest of the code.

-eric

>
>
>>
>> -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
>>>
>>
>
>
> --
> Alexey Samsonov
> vonosmas at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151021/8c8dd371/attachment.html>