[cfe-dev] Clang Address Sanitizer + Linker Set + Linker Section Alignment?

[Kyle Manna via cfe-dev]

Hi guys,

I started playing around with Clang's address sanitizer on a project that
uses linker sets to to store an array of structs in a linker section.

The code runs fine on clang, but when I pass '-fsanitize=address' it
breaks.  The spacing between the structs doubles.  Readelf reports an
alignment of 32 (vs 8, sizeof(struct) is actually 32 bytes).

Clang's docs warn that "AddressSanitizer is not expected to produce false
positives"
(ref: http://clang.llvm.org/docs/AddressSanitizer.html#issue-suppression).
Am I making a bad assumption regarding the layout of linker sections?

I have a simple GitHub project that reproduces the problem as well as a
travis-ci build that repeats the same result:
* https://github.com/kylemanna/cmocka-init
* https://travis-ci.org/kylemanna/cmocka-init/builds


With clang -fsanitize=address:

$ nm -n ./alignment
...
000000000070ac40 D __start_cmocka_init
000000000070ac40 D test_Simple_Init
000000000070ac80 D test_Simple_Life
000000000070acc0 D test_Test0
000000000070ad00 D test_Test1
000000000070ad40 D __stop_cmocka_init

$ readelf -S ./alignment
  [27] cmocka_init       PROGBITS         000000000070ac40  0010ac40
       0000000000000100  0000000000000000  WA       0     0     32

Note the alignment = 32.


Without clang -fsanitize=address:

$ nm -n ./alignment
...
0000000000609800 D __start_cmocka_init
0000000000609800 D test_Simple_Init
0000000000609820 D test_Simple_Life
0000000000609840 D test_Test0
0000000000609860 D test_Test1
0000000000609880 D __stop_cmocka_init

$ readelf -S ./alignment
  [25] cmocka_init       PROGBITS         0000000000609800  00009800
       0000000000000080  0000000000000000  WA       0     0     8

Also, gcc's address sanitizer doesn't appear to do anything.  It ignores
intentional issues (i.e. overflow) but also doesn't change the alignment.


- Kyle
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151005/e834e0b8/attachment.html>