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

Dmitry Vyukov dvyukov at google.com
Fri Aug 24 02:26:47 PDT 2012


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.



>
>
>>
>>>>
>>>>
>>>>>  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/159afbef/attachment.html>


More information about the llvm-commits mailing list