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

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>

On Wed, Oct 21, 2015 at 1:24 PM, Eric Christopher <echristo at gmail.com>
wrote:
>
>
> 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?
>
Yeah, I think it's correct to have LLVMSymbolizer own parsed object files
(although we might factor out a separate "cache" object
that would be responsible for it).

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

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

On Wed, Oct 21, 2015 at 2:18 PM Alexey Samsonov <vonosmas at gmail.com>
wrote:
> On Wed, Oct 21, 2015 at 1:24 PM, Eric Christopher <echristo at
gmail.com>
> wrote:
>
>>
>>
>> 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?
>>
>
> Yeah, I think it's correct to have LLVMSymbolizer own parsed object
files
> (although we might factor out a separate "cache" object
> that would be responsible for it).
>
OK. Sounds good to me. It can also be changed in the future if we decide to
go a different way.

-eric

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