On Tue, Oct 16, 2012 at 03:50:27PM -0700, Xinliang David Li wrote:
> Does that mean that all globals defined in shared libraries can not be
> protected as long as they are not protected or hidden? This sounds
> like a big limitation. We need to answer the following two questions:
For !DECL_ONE_ONLY !DECL_COMMON vars you can protect them just fine,
just do:
.globl i
.data
.align 32
.type i, @object
.size i, 4
i:
.long 7
.skip 60
.set .LASAN.i,i
and refer to .LASAN.i (i.e. a local alias) instead of i (or, as I said
earlier, with ABI change of __asan_*register_globals or some alternative
entrypoint for that it can be .LASAN.i-. and thus a PC-relative, not
dynamic, relocation). If i is preempted by a different i in another
library, each shared library simply protects the red zone after its own var,
and the fact that only one i is actually used by the program doesn't matter
much.
> 1) How often are exported variables get preempted?
It is not uncommon, and DECL_ONE_ONLY is preempted very often.
> 2) Is it a common use case to mix -fasan and -fno-asan ?
-fasan shouldn't be an ABI option IMHO, and changing the size of globals is
ABI changing.
> > And for DECL_COMMON, you can't put any padding after a common variable
> > without making the size of the common var larger (and increasing its
> > alignment), both are undesirable for -fasan/-fno-asan mixing.
>
> If the linker picks the large one (which I believe it does), is that
> still a problem?
Yes. For copy relocations at least.
Jakub
