[llvm-commits] [Sanitizer] PATCH: external llvm-symbolizer tool for sanitizers

[Kostya Serebryany]

On Fri, Aug 24, 2012 at 1:26 PM, Dmitry Vyukov <dvyukov at google.com> wrote:

> On Fri, Aug 24, 2012 at 10:44 AM, Alexey Samsonov <samsonov at google.com>wrote:
>
>> On Thu, Aug 23, 2012 at 3:52 PM, Alexey Samsonov <samsonov at google.com>wrote:
>>>
>>>>
>>>>>  And a follow-up from looking at the output. File/line numbers seem to
>>>>>> be fetched correctly, but that isn't always true for function names:
>>>>>> if instruction belongs to inlined instance of a function, then we may
>>>>>> (and often do) instead return the function it is inlined into.
>>>>>>
>>>>>
>>>>> It is the correct behavior.
>>>>>
>>>>
>>>> Not quite :) I mean, we output file/line/column of inlined function and
>>>> function name of function it is inlined into.
>>>>
>>>>
>>>
>>> Then it's file/line/column that's incorrect.
>>>
>>
>>>
>>>> As a bonus we may also output inlined frames, but by default we must
>>>>> output inlined-into frame.
>>>>>
>>>>
>> No. If you want to symbolize, say, some random "xor" instruction in the
>> code, you'd want to see the actual place in code where this
>> xor instruction takes place, not some place where it was inlined, 5
>> frames upper. This is what addr2line does.
>> Anyway, I see it's just time to implement reading information about
>> inlined frames.
>>
>
>
> I would like to see inlined-into frame. First, it's usually more
> informative. Second, that's what I will see in objdump/gdb.
>
That's not in the context of the current patch, is it?

>
>
>
>>
>>
>>>
>>>>>
>>>>>
>>>>>>  This
>>>>>> should be fixed in DebugInfo library, I'll work on that.
>>>>>>
>>>>>> On Thu, Aug 23, 2012 at 2:30 PM, Kostya Serebryany <kcc at google.com>wrote:
>>>>>>
>>>>>>> Excellent numbers!
>>>>>>> addr2line performance and memory usage has been the greatest
>>>>>>> inconvenience for many users.
>>>>>>> Please commit unless there are objections from someone else.
>>>>>>>
>>>>>>> --kcc
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 23, 2012 at 2:05 PM, Alexey Samsonov <
>>>>>>> samsonov at google.com> wrote:
>>>>>>>
>>>>>>>> For the record, I've ran some measurements on Chromium (fetched
>>>>>>>> random instruction addresses from binary and symbolized them with a tool):
>>>>>>>>
>>>>>>>> chrome + "-gline-tables-only" (0.5G binary)
>>>>>>>> tool             # of addresses       time                memory
>>>>>>>> addr2line     1                          0m16.803s
>>>>>>>> symbolizer   1                          0m0.501s
>>>>>>>> addr2line     100                       0m22.474s
>>>>>>>> symbolizer   100                       0m1.417s
>>>>>>>> addr2line     10k                       1m45.055s     2.1G
>>>>>>>> symbolizer   10k                       1m23.271s     440 Mb
>>>>>>>>
>>>>>>>> chrome + "-g" (2G binary):
>>>>>>>> addr2line     1                          0m36.101s
>>>>>>>> symbolizer   1                          0m10.101s
>>>>>>>> addr2line     100                       0m46.125s
>>>>>>>> symbolizer   100                       0m10.005s
>>>>>>>> addr2line     10k                       2m32.614s     9.2G
>>>>>>>> symbolizer   10k                       1m41.288s     3.9G
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 21, 2012 at 7:34 PM, Alexey Samsonov <
>>>>>>>> samsonov at google.com> wrote:
>>>>>>>>
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> This code contains a stand-alone file that makes use of existing
>>>>>>>>> LLVM libraries to symbolize instruction addresses of a module.
>>>>>>>>> Though it looks like an another llvm tool, we can temporary keep
>>>>>>>>> it at //projects/compiler-rt (as currently we're the only interested users,
>>>>>>>>> and we need to compile this tool for the same targets we build
>>>>>>>>> ASan/TSan for). This file may be run in a separate process, and
>>>>>>>>> communicate with caller via stdin/stdout. The key differences from
>>>>>>>>> addr2line is that the tool is capable of symbolizing code from
>>>>>>>>> different modules and is able to consult both symbol table and
>>>>>>>>> debug info for fetching function name (which would be helpful
>>>>>>>>> if the binary is compiled with -gline-tables-only).
>>>>>>>>>
>>>>>>>>> Code review: http://codereview.appspot.com/6465080/
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Alexey Samsonov, MSK
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Alexey Samsonov, MSK
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Alexey Samsonov, MSK
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Alexey Samsonov, MSK
>>>>
>>>>
>>>
>>
>>
>> --
>> Alexey Samsonov, MSK
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120824/4d7448bd/attachment.html>