On Tue, Oct 16, 2012 at 4:02 PM, Jakub Jelinek <ja...@redhat.com> wrote: > 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. >
Ok, using local aliases for those cases sound good. >> 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. > I am not sure -- fasan is an error detecting feature -- the goal is to find bugs -- missing handling of commons etc. are not desirable. Besides if ABI changes consistently for all objects, why does it matter? Or making common/decl_one_only protected under an additional option. thanks, David >> > 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
