Yuri, this comes from yours http://llvm.org/viewvc/llvm-project?view=revision&revision=205308 Could you please take a look?
On Thu, May 22, 2014 at 11:54 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Thu, May 22, 2014 at 09:43:01PM +0200, Paolo Carlini wrote: >> Hi, >> >> On 05/22/2014 09:15 PM, Jakub Jelinek wrote: >> >Do you have LD_PRELOAD set in the environment? >> I don't. >> >If not, can you cut'n'paste the large-func-test-1.exe command line >> >and run it with the given LD_LIBRARY_PATH under ldd? Jakub >> Sure. This is what I get: >> >> linux-vdso.so.1 (0x00007fffee578000) >> libasan.so.1 => >> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs/libasan.so.1 >> (0x00007f41610c7000) >> libstdc++.so.6 => >> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so.6 >> (0x00007f4160db6000) >> libm.so.6 => /lib64/libm.so.6 (0x00007f4160ab3000) >> libgcc_s.so.1 => >> /home/paolo/Gcc/svn-dirs/trunk-build/gcc/libgcc_s.so.1 >> (0x00007f416089c000) >> libc.so.6 => /lib64/libc.so.6 (0x00007f41604ed000) >> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f41602cf000) >> libdl.so.2 => /lib64/libdl.so.2 (0x00007f41600cb000) >> /lib64/ld-linux-x86-64.so.2 (0x00007f4161ff3000) > > Kostya, guess you should ignore the vDSO. > > I'd say the test is useless anyway, if you really want to do some > quick sanity check, much better would be just dlsym a couple of > interesting symbols to verify that libasan.so.1 is ahead > of libc.so.6, libstdc++.so.6, libpthread.so.0 (whatever else > you want to override). Otherwise libasan apps will simply stop > working altogether if LD_PRELOAD is set, to whatever library, > even if it doesn't define any symbols you care about. > I'd verify that malloc, memcpy, pthread_create, operator new > all resolve to the libasan.so.1 copy (if all those have local aliases, > just compare what dlsym returns with those local aliases). > Typically people in LD_PRELOAD override malloc (which we want to diagnose), > or far more rarely stringops (e.g. memstomp, also undesirable). > > Jakub
