i386 -faddress-sanitizer

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

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.

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/.o -lstdc++ -v -faddress-sanitizer
-shared
-L/usr/local/lib/erlang/lib/erl_interface-3.7.8/lib
-lerl_interface -lei -o priv/.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/.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/.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
:slight_smile:

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

More correct would be to say "it's meaningless to link a shared
object with -faddress-sanitizer because pnly the runtime loading
the shared object has to be linked with -faddress-sanitizer".