clang and clang++ behave differently on a small OOB test about address-sanitizer

[GoogleCodeExporter]

There are some warnings about -Warray-bounds reported by both clang and 
clang++, but passing -Wno-array-bounds does not fix the problem

Original comment by [email protected] on 17 Jan 2012 at 12:24

[GoogleCodeExporter]

$ ../../../../build/Release+Asserts/bin/clang  t.c -S -emit-llvm -o t.ll -O3
$ ../../../../build/Release+Asserts/bin/clang++  t.c -S -emit-llvm -o tpp.ll -O3
============================================================
$ diff t.ll tpp.ll
5c5
< @a = common global [5 x i32] zeroinitializer, align 16
---
> @a = global [5 x i32] zeroinitializer, align 16

============================================================
$ cat t.ll
; ModuleID = 't.c'
target datalayout = 
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v6
4:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.6.8"

@a = common global [5 x i32] zeroinitializer, align 16

define i32 @main() nounwind uwtable ssp {
entry:
  store volatile i32 1, i32* getelementptr inbounds ([5 x i32]* @a, i64 1, i64 0), align 4, !tbaa !0
  ret i32 0
}

!0 = metadata !{metadata !"int", metadata !1}
!1 = metadata !{metadata !"omnipotent char", metadata !2}
!2 = metadata !{metadata !"Simple C/C++ TBAA", null}
============================================================

$ cat tpp.ll
; ModuleID = 't.c'
target datalayout = 
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v6
4:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.6.8"

@a = global [5 x i32] zeroinitializer, align 16

define i32 @main() nounwind uwtable ssp {
entry:
  store volatile i32 1, i32* getelementptr inbounds ([5 x i32]* @a, i64 1, i64 0), align 4, !tbaa !0
  ret i32 0
}

!0 = metadata !{metadata !"int", metadata !1}
!1 = metadata !{metadata !"omnipotent char", metadata !2}
!2 = metadata !{metadata !"Simple C/C++ TBAA", null}

Original comment by [email protected] on 17 Jan 2012 at 12:25

[GoogleCodeExporter]

Looks like AddressSanitizer.cpp explicitly ignores globals with "common" 
linkage:

396     // Touch only those globals that will not be defined in other modules.
397     // Don't handle ODR type linkages since other modules may be built w/o 
asan.
398     if (G->getLinkage() != GlobalVariable::ExternalLinkage &&
399         G->getLinkage() != GlobalVariable::PrivateLinkage &&
400         G->getLinkage() != GlobalVariable::InternalLinkage)
401       continue;

Kostya, what will break down if we add CommonLinkage here?

As per http://llvm.org/docs/LangRef.html#linkage_common:

common
"common" linkage is most similar to "weak" linkage, but they are used for 
tentative definitions in C, such as "int X;" at global scope. Symbols with 
"common" linkage are merged in the same way as weak symbols, and they may not 
be deleted if unreferenced. common symbols may not have an explicit section, 
must have a zero initializer, and may not be marked 'constant'. Functions and 
aliases may not have common linkage.

Or maybe clang should not mark such global definitions as common?

Original comment by [email protected] on 17 Jan 2012 at 12:48

[GoogleCodeExporter]

We can not handle symbols with common linkage because such symbols 
may be redefined in another file to have a different size. 


% head a1.c* a2.c*
==> a1.c <==
int xxx;

==> a1.cc <==
int xxx;

==> a2.c <==
double xxx;
int main() { }

==> a2.cc <==
double xxx;
int main() { }
% clang a1.c a2.c
% clang++ a1.cc a2.cc
/tmp/a2-aqRav2.o:(.bss+0x0): multiple definition of `xxx'
/tmp/a1-7Snei5.o:(.bss+0x0): first defined here
/usr/bin/ld: Warning: size of symbol `xxx' changed from 4 in /tmp/a1-7Snei5.o 
to 8 in /tmp/a2-aqRav2.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
% 

Original comment by [email protected] on 17 Jan 2012 at 6:13

• Changed state: WontFix

[GoogleCodeExporter]

Adding Project:AddressSanitizer as part of GitHub migration.

Original comment by [email protected] on 30 Jul 2015 at 9:12

• Added labels: ProjectAddressSanitizer