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

[Alexey Samsonov]

On Thu, Aug 23, 2012 at 3:58 PM, Dmitry Vyukov <dvyukov 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.


>
>>>
>>>
>>>>  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/2aa28185/attachment.html>