[cfe-dev] i386 -faddress-sanitizer

Sat Oct 20 06:46:19 PDT 2012

On Sat, Oct 20, 2012 at 3:15 PM, Carsten Mattner
<carstenmattner at gmail.com>wrote:

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

Yes, asan exits on the first error, this is by design.
(hm, I guess we need to make a FAQ entry about this... Will do.)

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

LDFLAGS may contain  -faddress-sanitizer when building DSOs -- it won't
hurt but it will be ignored.

--kcc

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.
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121020/51abedb8/attachment.html>