[cfe-dev] Debug info broken for ASan-instrumented binaries

Eric Christopher echristo at gmail.com
Mon Mar 31 09:34:57 PDT 2014


On Mon, Mar 31, 2014 at 7:21 AM, Alexey Samsonov <samsonov at google.com> wrote:
> Hi Martin,
>
> Sorry for the late response.
> This is tracked in
> https://code.google.com/p/address-sanitizer/issues/detail?id=235
> In short - there is a bug in LLVM DWARF generation, that fires rarely on a
> regular C++ code (especially with -O0),
> but breaks debug info if we instrument the code with ASan. I've looked at
> this issue and had some ideas
> about how this should be fixed, but didn't finish the work yet.
>

Yeah, let's pick this back up. Can you ping the original thread where
you started looking into this?

-eric

> On Thu, Mar 27, 2014 at 3:04 PM, Kostya Serebryany <kcc at google.com> wrote:
>>
>> +samsonov@
>>
>>
>> On Thu, Mar 27, 2014 at 2:46 PM, Richtarsky, Martin
>> <martin.richtarsky at sap.com> wrote:
>>>
>>> Hi,
>>>
>>> I noticed that debugging of AddressSanitizer-instrumented debug binaries
>>> is basically impossible since all the symbols are optimized out. It looks
>>> like
>>> there is something wrong with debug info. I'm getting the same behavior
>>> on 3.4 and trunk. Interestingly it works for -fsanitize=undefined. Is
>>> this a known
>>> issue? There are several related bugs but they are fixed already, e.g.
>>> http://llvm.org/bugs/show_bug.cgi?id=11818
>>>
>>> # cat UnitAsanStackOOB.cpp
>>> int main()
>>> {
>>>     const int len = 10;
>>>     char buffer[len];
>>>     char *p = &buffer[0];
>>>     p[len] = 1;
>>>     return 0;
>>> }
>>>
>>> # clang++ -g -o oob_trunk_add -fsanitize=address UnitAsanStackOOB.cpp
>>> # gdb oob_trunk_add
>>> GNU gdb (GDB) 7.5.1
>>> Reading symbols from
>>> /local/build/git5/sys/src/clang/AddressSanitizer/test/oob_trunk_add...done.
>>> (gdb) b main
>>> Breakpoint 1 at 0x495a4a: file UnitAsanStackOOB.cpp, line 3.
>>> (gdb) run
>>> Starting program:
>>> /local/build/git5/sys/src/clang/AddressSanitizer/test/oob_trunk_add
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>> Breakpoint 1, main () at UnitAsanStackOOB.cpp:3
>>> 3           const int len = 10;
>>> (gdb) n
>>> 5           char *p = &buffer[0];
>>> (gdb) n
>>> 6           p[len] = 1;
>>> (gdb) p p
>>> $1 = <optimized out>
>>> (gdb) p len
>>> $2 = <optimized out>
>>>
>>> # clang++ -g -o oob_trunk_und -fsanitize=undefined UnitAsanStackOOB.cpp
>>> # gdb oob_trunk_und
>>> GNU gdb (GDB) 7.5.1
>>>  (gdb) b main
>>> Breakpoint 1 at 0x426280: file UnitAsanStackOOB.cpp, line 2.
>>> (gdb) run
>>> Starting program:
>>> /local/build/git5/sys/src/clang/AddressSanitizer/test/oob_trunk_und
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>> Breakpoint 1, main () at UnitAsanStackOOB.cpp:2
>>> 2       {
>>> (gdb) n
>>> 3           const int len = 10;
>>> (gdb) n
>>> 5           char *p = &buffer[0];
>>> (gdb) n
>>> 6           p[len] = 1;
>>> (gdb) p p
>>> $1 = 0x7fffffff975e ""
>>> (gdb) p len
>>> $2 = 10
>>>
>>> # clang++ -v
>>> clang version 3.5.0 (trunk 204863)
>>> Target: x86_64-unknown-linux-gnu
>>> Thread model: posix
>>> Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.3
>>> Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.3
>>> Candidate multilib: .;@m64
>>> Candidate multilib: 32;@m32
>>> Selected multilib: .;@m64
>>>
>>> Best regards,
>>> Martin
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
>
>
> --
> Alexey Samsonov, MSK
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>



More information about the cfe-dev mailing list