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

[Alexey Samsonov via llvm-dev]

On Wed, Oct 21, 2015 at 2:19 PM, Eric Christopher <echristo at gmail.com>
wrote:

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

See http://reviews.llvm.org/D13998


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


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