[llvm-dev] RFC: Move parts of llvm-symbolizer tool implementation to LLVMSymbolize library

[Eric Christopher via llvm-dev]

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>