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

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>

On Wed, Oct 21, 2015 at 12:59 PM, Eric Christopher <echristo at gmail.com>
wrote:
>
>
> 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?
>
For a start, yes.

> 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.
>
I'm not sure what you mean by this.

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

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

On Wed, Oct 21, 2015 at 1:21 PM Alexey Samsonov <vonosmas at gmail.com>
wrote:
> On Wed, Oct 21, 2015 at 12:59 PM, Eric Christopher <echristo at
gmail.com>
> wrote:
>
>>
>>
>> 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?
>>
>
> For a start, yes.
>
OK.

>
>
>> 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.
>>
>
> I'm not sure what you mean by this.
>
>
Is LLVMSymbolizer owning all of the files the right choice, or what was
convenient at the time?

-eric

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