[cfe-dev] i386 -faddress-sanitizer

Carsten Mattner carstenmattner at gmail.com
Sat Oct 20 04:15:50 PDT 2012


On Fri, Oct 19, 2012 at 9:07 AM, Kostya Serebryany <kcc at google.com> wrote:
>
>
> On Fri, Oct 19, 2012 at 12:50 AM, Carsten Mattner <carstenmattner at gmail.com>
> wrote:
>>
>> On Thu, Oct 18, 2012 at 6:27 PM, Kostya Serebryany <kcc at google.com> wrote:
>> >
>> >
>> > On Thu, Oct 18, 2012 at 8:19 PM, Carsten Mattner
>> > <carstenmattner at gmail.com>
>> > wrote:
>> >>
>> >> 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
>> >
>> >
>> > Hm. I don't see any reason for the failure here... Anyone?
>>
>> Is the probably special handling for .so files that automatically
>> prevents linking in asan.a?
>
>
>
> In the clang driver we check what is being linked and pass libasan.a to ld
> only if the final executable is being linked.
> So, a shared library just doesn't get linked with asan.a, but it still has
> __asan_report_* callbacks,
> which may cause link errors if you are using -Wl,-z,defs (or something
> similar).
> Looks like you have resolved the problem, right?

Yes after being told which parts need to be built with or without
-faddress-sanitizer it was simple to use.

> Let us know if the tool works for your case (and if you find bugs in Erlang
> :)

Is runtime abort upon detecting an error the expected effect?
Anything else?

> BTW, I've extended the docs a bit:
> http://clang.llvm.org/docs/AddressSanitizer.html#usage

Thanks. I believe you should explicity document that LDFLAGS
when building a shared object should not contain -faddress-sanitizer
because it's not how it's meant to be used - as I found out.

> --kcc
>
>>
>>
>> >> > 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.
>> >
>> > You need to use -faddress-sanitizer while building the objects you
>> > want to test. You don't need to instrument Erlang sources (but most
>> > likely it won't hurt), just make sure that -faddress-sanitizer is
>> > passed to the link command.
>>
>> That's good to know if all I want to check are faults in my
>> shared object only.
>>
>> > BTW, we have the same problem with python.
>> > In our private setting we solved it with "LD_PRELOAD=asan.so python
>> > x.py",
>> > but I would not recommend this as a generally good approach.
>> >
>> >>
>> >>
>> >> Is this detail documented?
>> >
>> >
>> > Probably no. I think we explain *how* asan works in detail, from which
>> > you
>> > can deduct these limitations,
>> > but that's not trivial.
>> >
>> >>
>> >> If not maybe it should
>> >
>> >
>> > Mmm. Perhaps.
>
>



More information about the cfe-dev mailing list