This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libsanitizer] merge fresh sources from upstream


Ok, the tests behave better on ubuntu 12.04.
tested:
rm -rf rm -rf */{*/,}libsanitizer && make -j20 && make -C gcc
check-g{cc,++} RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
asan.exp'

The fresh asan library produces slightly different output (added ':'),
so the tests (all 1 of them) have been updated.
Please take another look.


--kcc




On Fri, Nov 23, 2012 at 4:53 PM, Konstantin Serebryany
<konstantin.s.serebryany@gmail.com> wrote:
> On Fri, Nov 23, 2012 at 4:47 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Fri, Nov 23, 2012 at 04:35:29PM +0400, Konstantin Serebryany wrote:
>>> > Ok, provided it has been properly tested
>>>
>>> The upstream library is continuously tested on Linux, Mac, Windows and Android
>>> using the existing test suite (unfortunately, the build bots are
>>> private so far).
>>
>> Yeah, but one thing is testing it inside of llvm built with clang, and
>> another one to test what is in the gcc tree.  We really don't want to break
>> bootstrap again (happened for some time immediately after asan was merged
>> and for 4 revisions again for i686-linux when tsan was merged).
>>
>>> > make -C gcc check-g{cc,++} RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'
>>>
>>> The tests fail even w/o this change for me.
>>> The reports look like
>>>     #0 0x555c96f2 in  ??:0
>>>     #1 0x80488d1 in  ??:0
>>> i.e. either the debug info is missing or the symbolizer script is not working.
>>> Any suggestion?
>>
>> That is strange.  What addr2line you are using?  If you look at
>
> I have ubuntu 10.04 (pretty old, I admit) and use it's standard addr2line.
>
>
>> gcc/testsuite/gcc/gcc.log
>> there should be lines like
>>
>> Executing on host: addr2line -f -e /usr/lib64/libc-2.15.so 0x21734   (timeout = 300)
>> spawn -ignore SIGHUP addr2line -f -e /usr/lib64/libc-2.15.so 0x21734
>
>
> I get these:
>
>
> Executing on host: addr2line -f -e
> /usr/local/google/kcc/gcc-build/gcc/testsuite/gcc/memcmp-1.exe
> 0x80488d1 0x8048560   (timeout = 300)
> spawn addr2line -f -e
> /usr/local/google/kcc/gcc-build/gcc/testsuite/gcc/memcmp-1.exe
> 0x80488d1 0x8048560
> BFD: Dwarf Error: found dwarf version '4', this reader only handles
> version 2 and 3 information.
> main
> ??:0
> BFD: Dwarf Error: found dwarf version '0', this reader only handles
> version 2 and 3 information.
> _start
> ??:0
>
> Let me try to build gcc on a newer ubuntu 12.04 and see what happens.
> Do you think it may help?
>
>
>> ??
>> ??:0
>> Executing on host: addr2line -f -e /usr/src/gcc/obj2/gcc/testsuite/gcc/memcmp-1.exe 0x400a19   (timeout = 300)
>> spawn -ignore SIGHUP addr2line -f -e /usr/src/gcc/obj2/gcc/testsuite/gcc/memcmp-1.exe 0x400a19
>> main
>> ??:0
>> Executing on host: addr2line -f -e /usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.so.0.0.0 0xb52f   (timeout = 300)
>> spawn -ignore SIGHUP addr2line -f -e /usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.so.0.0.0 0xb52f
>> memcmp
>> ??:0
>>
>> if using oldish addr2line which understands DWARF4, but doesn't cope with
>> constant class DW_AT_high_pc that GCC 4.8 now emits, or
>> like:
>>
>> Executing on host: addr2line -f -e /usr/lib64/libc-2.15.so 0x21734   (timeout = 300)
>> spawn -ignore SIGHUP addr2line -f -e /usr/lib64/libc-2.15.so 0x21734
>> ??
>> ??:0
>> Executing on host: addr2line -f -e /usr/src/gcc/obj2/gcc/testsuite/gcc/memcmp-1.exe 0x400a19   (timeout = 300)
>> spawn -ignore SIGHUP addr2line -f -e /usr/src/gcc/obj2/gcc/testsuite/gcc/memcmp-1.exe 0x400a19
>> main
>> /usr/src/gcc/gcc/testsuite/c-c++-common/asan/memcmp-1.c:12
>> Executing on host: addr2line -f -e /usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.so.0.0.0 0xb52f   (timeout = 300)
>> spawn -ignore SIGHUP addr2line -f -e /usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.so.0.0.0 0xb52f
>> __interceptor_memcmp
>> /usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libsanitizer/asan/../../../../libsanitizer/asan/asan_interceptors.cc:218
>>
>> if using recent enough addr2line.
>>
>>> Ooops. I actually edited it. How do I regenerate it? (I beg my pardon
>>> for a complete ignorance)
>>
>> Well, in this case there should be really no difference, regeneration
>> should generate exactly what you hand edited I think.
>> But generally, one needs to use the standard GCC versions of
>> autoconf/automake (right now 2.64 and 1.11),
>
> Gotcha!
> This is what confused me (I have autoconf 2.65 and was surprised to
> see it not working...)
>
>> and just run autoconf
>> (autoheader not needed for libsanitizer) and automake.
>> As people usually have different versions of the autotools installed, I
>> usually do
>> PATH=~/automake-1.11/bin:~/autoconf-2.64/bin:$PATH autoconf
>> PATH=~/automake-1.11/bin:~/autoconf-2.64/bin:$PATH automake
>> where I've installed autoconf and automake with the ~/automake-1.11 resp.
>> ~/autoconf-2.64 --prefix.
>>
>>         Jakub

Attachment: libsanitizer_168514.patch
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]