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: [PATCH] Use libbacktrace as libsanitizer's symbolizer


+eugenis, dvyukov
libbacktrace doesn't call malloc -- good.
Most other functions it does call (memset,strlen, etc) will be
rerouted to sanitizer interceptors.
This is just generally scary and I think we've been hit by this in
reality with early llvm-symbolizer.
More likely in tsan and msan than in asan.
Evgeniy, Dmitry, do you remember any details?

--kcc


On Fri, Nov 22, 2013 at 10:57 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Nov 22, 2013 at 10:40:00PM +0400, Konstantin Serebryany wrote:
>> [I beg my pardon if this has already been discussed here]
>> Does libbacktrace call any functions we intercept (malloc, memset,
>> memcpy, strlen, etc)?
>> If so, they will have to be un-intercepted there.
>
> Why?
>
>> Our hermetic llvm-symbolizer took as so much work for a reason. :(
>> And doing this work for libbacktrace w/o any additional functionality
>> for us is kind of sad...
>
> The symbols from libc/libgcc used in my libbacktrace.a are following:
>
> dwarf.o:
>                  U bsearch
>                  U memcpy
>                  U memset
>                  U qsort
>                  U snprintf
>                  U strcmp
>                  U strlen
>                  U strnlen
> posix.o:
>                  U close
>                  U __errno_location
>                  U fcntl
>                  U open
> print.o:
>                  U fprintf
>                  U fputc
>                  U stderr
>                  U strerror
> backtrace.o:
>                  U _Unwind_Backtrace
>                  U _Unwind_GetIPInfo
> simple.o:
>                  U _Unwind_Backtrace
>                  U _Unwind_GetIPInfo
> elf.o:
>                  U bsearch
>                  U dl_iterate_phdr
>                  U qsort
>                  U strcmp
> mmapio.o:
>                  U __errno_location
>                  U getpagesize
>                  U mmap
>                  U munmap
> mmap.o:
>                  U __errno_location
>                  U getpagesize
>                  U memcpy
>                  U mmap
>
> Note that I think neither print.o nor backtrace.o nor simple.o
> were actually linked into libasan* with my earlier patch, so
> the list of external symbols is likely just:
>                  U bsearch
>                  U memcpy
>                  U memset
>                  U qsort
>                  U snprintf
>                  U strcmp
>                  U strlen
>                  U strnlen
>                  U close
>                  U __errno_location
>                  U fcntl
>                  U open
>                  U dl_iterate_phdr
>                  U getpagesize
>                  U mmap
>                  U munmap
>
> Now, what's wrong in using these symbols while symbolizing something?
> All the testing worked just fine for me, are you afraid there will be
> bugs in libbacktrace which would trigger recursive diagnostics?
>
> Worst case we could build a special copy of libbacktrace.la inside of
> libsanitizer rather than just use the target copy of it built for libgo
> (libbacktrace right now is used for GCC itself as host library and
> for libgo as target library), just by e.g. adding special
> libsanitizer/libbacktrace/Makefile.am rules to look for sources into
> ../../libbacktrace/ and say wrap libbacktrace's internal.h header so
> that it #include_next <internal.h> and then redefines the above mentioned
> functions or subset of them to the internal stuff.
>
> But before doing that, the question is why.
>
>         Jakub


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