[cfe-dev] i386 -faddress-sanitizer

[Carsten Mattner]

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
>> >
>> >
>
>