[cfe-dev] i386 -faddress-sanitizer

[Kostya Serebryany]

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?

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

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

--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/20121019/3de718b7/attachment.html>