[cfe-dev] i386 -faddress-sanitizer

Carsten Mattner carstenmattner at gmail.com
Thu Oct 18 09:19:14 PDT 2012 

On Thu, Oct 18, 2012 at 5:41 PM, Alexander Potapenko <glider at google.com> wrote:
> You have two issues here then.
> First, for some reason the linker doesn't like the unresolved calls to
> ASan runtime in your shared object. Can you please attach the full
> command line used to invoke the linker (feel free to obfuscate the
> file names if needed, but please keep the flags).

clang c_src/<PROJECT>.o -lstdc++ -v -faddress-sanitizer
  -shared
  -L/usr/local/lib/erlang/lib/erl_interface-3.7.8/lib
  -lerl_interface -lei -o priv/<PROJECT>.so
clang version 3.2 (http://llvm.org/git/clang.git
278eafa2cd8296f8128d13c6466a0ace3d03a872)
(http://llvm.org/git/llvm.git
2360b7ad99eedecaae512373e7be49c2143550cf)
Target: i386-pc-linux-gnu
Thread model: posix
 "/usr/bin/ld" --eh-frame-hdr -m elf_i386 -shared -o priv/<PROJECT>.so
 /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../crti.o
 /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/crtbeginS.o
 -L/usr/local/lib/erlang/lib/erl_interface-3.7.8/lib
 -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2
 -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../.. -L/lib -L/usr/lib
 c_src/<PROJECT>.o -lstdc++
 -lerl_interface -lei -lgcc --as-needed -lgcc_s
 --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
 /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/crtendS.o
 /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../crtn.o

> Second, you're going to have problems with unresolved symbols once you
> load your shared object into a non-instrumented executable.
> The only way to detect any errors in a shared library so far is to
> rebuild the executable loading that library with ASan.
> Please don't link libasan.a with the .so anyway, because you're likely
> to have problems with the initialization order. ASan runtime needs to
> be initialized at program startup.

This makes sense and I'll build an instrumented Erlang runtime
as a next step. With that in place do I still have to enable asan
in CFLAGS when building the object file? I would say yes.

Is this detail documented? If not maybe it should but I may have
been not reading carefully enough.

> On Thu, Oct 18, 2012 at 7:22 PM, Carsten Mattner
> <carstenmattner at gmail.com> wrote:
>> On Thu, Oct 18, 2012 at 5:18 PM, Kostya Serebryany <kcc at google.com> wrote:
>>>
>>>
>>> On Thu, Oct 18, 2012 at 7:00 PM, Carsten Mattner <carstenmattner at gmail.com>
>>> wrote:
>>>>
>>>> On Thu, Oct 18, 2012 at 4:49 PM, Kostya Serebryany <kcc at google.com> wrote:
>>>> > You are linking a shared object, asan.a should not be linked to it.
>>>>
>>>> What should happen instead?
>>>
>>>
>>> nothing. asan.a should be linked only to the main executable.
>>
>> I don't build an executable. This is a shared object which gets
>> loaded at runtime. Specifically it's a .so implementing a native
>> interface binding used with the Erlang runtime.
>>
>>>> > Are these all the flags passed to ld?
>>>>
>>>> Yes it's all minus project-specific -l and *.a and *.o args
>>>> I have omitted for the email.
>>>
>>>
>>> don't you have something like -Wl,-z,defs ?
>>> The problem you describe was seen before in the presence of -Wl,-z,defs,
>>> which forces the definitions of all symbols in .so (and __asan* symbols are
>>> not defined).
>>> The solution was to remove -Wl,-z,defs.
>>
>> I can't find any of that in the verbose clang linker call's logs.
>>
>>>> > On Thu, Oct 18, 2012 at 6:23 PM, Carsten Mattner
>>>> > <carstenmattner at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> On Thu, Oct 18, 2012 at 3:36 PM, Alexander Potapenko
>>>> >> <glider at google.com>
>>>> >> wrote:
>>>> >> > Can you append -v at the place it's being invoked to check whether
>>>> >> > the
>>>> >> > contents of LDFLAGS are being actually passed?
>>>> >>
>>>> >> $ clang <INPUT_OBJECTS> -lstdc++ -v -faddress-sanitizer -shared
>>>> >> <PROJECT_FLAGS> -o <SO_FILE>
>>>> >> clang
>>>> >> version 3.2 (http://llvm.org/git/clang.git
>>>> >> 278eafa2cd8296f8128d13c6466a0ace3d03a872)
>>>> >> (http://llvm.org/git/llvm.git
>>>> >> 2360b7ad99eedecaae512373e7be49c2143550cf)
>>>> >> Target: i386-pc-linux-gnu
>>>> >> Thread model: posix
>>>> >>
>>>> >> "/usr/bin/ld" --eh-frame-hdr -m elf_i386 -shared -o <SO_FILE>
>>>> >> /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../crti.o
>>>> >> /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/crtbeginS.o
>>>> >> -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2
>>>> >> -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../.. -L/lib -L/usr/lib
>>>> >> <INPUT_OBJECTS> -lstdc++ -lgcc --as-needed -lgcc_s --no-as-needed -lc
>>>> >> -lgcc --as-needed -lgcc_s --no-as-needed
>>>> >> /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/crtendS.o
>>>> >> /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../crtn.o
>>>> >>
>>>> >> I guess the libasan archive should be part of the above call to ld.
>>>> >>
>>>> >> > On Thu, Oct 18, 2012 at 5:33 PM, Carsten Mattner
>>>> >> > <carstenmattner at gmail.com> wrote:
>>>> >> >> On Thu, Oct 18, 2012 at 3:29 PM, Alexander Potapenko wrote:
>>>> >> >>> Are you linking with ld or clang?
>>>> >> >>> -faddress-sanitizer is a Clang flag, so if you're running `ld
>>>> >> >>> $LDFLAGS
>>>> >> >>> ...` to link your program, it won't work.
>>>> >> >>
>>>> >> >> clang.
>>>> >> >>
>>>> >> >>> On Thu, Oct 18, 2012 at 5:12 PM, Carsten Mattner
>>>> >> >>> <carstenmattner at gmail.com> wrote:
>>>> >> >>>> On Thu, Oct 18, 2012 at 12:27 AM, Eli Friedman wrote:
>>>> >> >>>>> On Wed, Oct 17, 2012 at 1:43 PM, Carsten Mattner
>>>> >> >>>>> <carstenmattner at gmail.com> wrote:
>>>> >> >>>>>> Is it expected that -faddress-sanitizer  does not work on i386
>>>> >> >>>>>> and
>>>> >> >>>>>> fails
>>>> >> >>>>>> to properly link resulting in errors like 'undefined symbol:
>>>> >> >>>>>> __asan_init'
>>>> >> >>>>>> at runtime?
>>>> >> >>>>>>
>>>> >> >>>>>> I have ./lib/clang/3.2/lib/linux/libclang_rt.asan-i386.a in
>>>> >> >>>>>> llvm's
>>>> >> >>>>>> installation,
>>>> >> >>>>>> but it doesn't look like it's linked automatically into the
>>>> >> >>>>>> executable.
>>>> >> >>>>>>
>>>> >> >>>>>> CFLAGS:
>>>> >> >>>>>> -faddress-sanitizer -O1 -fno-omit-frame-pointer -g
>>>> >> >>>>>> $PROJECT_FLAGS
>>>> >> >>>>>
>>>> >> >>>>> You need to pass in -faddress-sanitizer both when compiling and
>>>> >> >>>>> when
>>>> >> >>>>> linking an application.  Try something like
>>>> >> >>>>> "LDFLAGS=-faddress-sanitizer".
>>>> >> >>>>
>>>> >> >>>> Oh that makes a lot of sense and is kind of obvious in hindsight.
>>>> >> >>>> Yet it didn't work in a quick test. Any options I flags to pass
>>>> >> >>>> for
>>>> >> >>>> verbose printfs to see what's happening you can suggest?
>>>> >> >>>> In the next test I'll also try to explicitly link the libasan
>>>> >> >>>> archive
>>>> >> >>>> manually for ruling out issues with that archive.
>>>> >> >>>> _______________________________________________
>>>> >> >>>> cfe-dev mailing list
>>>> >> >>>> cfe-dev at cs.uiuc.edu
>>>> >> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>> >> >>>
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> --
>>>> >> >>> Alexander Potapenko
>>>> >> >>> Software Engineer
>>>> >> >>> Google Moscow
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > --
>>>> >> > Alexander Potapenko
>>>> >> > Software Engineer
>>>> >> > Google Moscow
>>>> >> _______________________________________________
>>>> >> cfe-dev mailing list
>>>> >> cfe-dev at cs.uiuc.edu
>>>> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>> >
>>>> >
>>>
>>>
>
>
>
> --
> Alexander Potapenko
> Software Engineer
> Google Moscow

More information about the cfe-dev mailing list