This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug sanitizer/55739] asan doesn't work on common symbols


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-17 17:48:18 UTC ---
No idea why you keep mentioning
       .quad    common_data
       .quad    common_data@size
       .quad    common_data@size + 40
That is nothing even close to what asan needs.  Asan for what is normally
emitted e.g. as:
.comm common_data,15,4
needs to emit
.comm common_data,64,32
instead, and then a hidden alias to common_data (currently not allowed by as)
or some new relocations which will result in the address of the common_data
copy in current executable resp. shared library, followed by 15 (the size of
the real common_data), followed by common_data@size (which will be either 15 or
64, depending on how large is common_data actually allocated).
This still relies on the the linker always choosing the highest alignment from
all the alignments of the same var (because libasan relies that all such
variables are at least 32 bytes aligned), and if merging of common vars in
whatever order always results in highest size being picked, then we even don't
need any of this @size stuff at all.  The problem is that if you link say a
shared library or executable where you have some -fsanitize=address compiled
common vars and then some non-sanitized object with the var initialized (i.e.
non-common), then the non-common var wins, but a) doesn't get appropriately
aligned (so, impossible to be passed to asan register function), and b) not
appropriately sized.
Consider: 1.c:
asm (".globl foo; .comm foo,4,4;");
2.c:
asm (".globl foo; .comm foo,64,32;");
3.c:
asm (".globl foo; .comm foo,4,4;");
4.c:
int foo = 6;

(1.c and 3.c emulate -fno-sanitize=address common var, 4.c non-sanitized
non-common var, 2.c sanitized common var).  Now,
gcc -shared -fpic -o test.so 1.c 2.c 3.c
seems to DTRT, foo is 32-byte aligned and 64-bytes long, so we could register
it as foo's hidden alias, 4, 64.  But if you
gcc -shared -fpic -o test.so 1.c 2.c 3.c 4.c
you get:
/usr/bin/ld: Warning: alignment 4 of symbol `foo' in /tmp/ccoadfJM.o is smaller
than 32 in /tmp/cc8Dhbe7.o
/usr/bin/ld: Warning: size of symbol `foo' changed from 64 in /tmp/cc8Dhbe7.o
to 4 in /tmp/ccoadfJM.o

No @size stuff helps with this.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]