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.

Reply via email to