This is the mail archive of the gcc-patches@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]

Re: r196201 - in /trunk: gcc/ChangeLog gcc/config/i...


On Fri, Feb 22, 2013 at 05:56:34PM +0400, Konstantin Serebryany wrote:
> Is there a use case where __attribute__((constructor)) in asan_rtl.cc
> will improve our chances to run early?

I was thinking about something like:
cat > libab.C <<\EOF
static int a[10], b;
extern "C" void bar (void) __attribute__((noinline, noclone));

extern "C" void
bar (void)
{
  asm volatile ("" : : : "memory");
  a[b]++;
  asm volatile ("" : : : "memory");
  __builtin_printf ("libab bar\n");
}

static struct B
{
  B ();
} c;

B::B ()
{
  asm volatile ("" : : : "memory");
  a[b]++;
  asm volatile ("" : : : "memory");
  __builtin_printf ("B::B ()\n");
  bar ();
}
EOF
cat > libaa.C <<\EOF
static int a[10], b;
extern "C" void bar (void) __attribute__((noinline, noclone));

extern "C" void
bar (void)
{
  asm volatile ("" : : : "memory");
  a[b]++;
  asm volatile ("" : : : "memory");
  __builtin_printf ("libaa bar\n");
}

static struct A
{
  A ();
} c;

A::A ()
{
  asm volatile ("" : : : "memory");
  a[b]++;
  asm volatile ("" : : : "memory");
  __builtin_printf ("A::A ()\n");
  bar ();
}
EOF
cat > a.c <<\EOF
int a[10];

int
main ()
{
  int i = 11;
  asm volatile ("" : "+r" (i));
  a[i] = 1;
  return 0;
}
EOF
g++ -shared -fpic -o libab.so libab.C
g++ -shared -fsanitize=address -fpic -o libaa.so libaa.C ./libab.so
gcc -g -o a a.c -B ./ -Wl,-rpath-link,.,-rpath,. -laa
./a

With the constructor attribute, you can at least fix this by
LD_PRELOAD=libasan.so.0 ./a

Without it it will just crash.

So it serves at least as a workaround for the cases where you don't want or
can't for some reason instrument the executable, and e.g. libc, libpthread
otherwise are found earlier in the search scope (then generally libasan
doesn't really work) or some constructor of a non-instrumented library calls
into a symbol earlier in the search scope in a library which has been
instrumented.

Also note that this isn't a libasan.a vs. libasan.so debate, but rather
a debate about whether we can only support instrumented binaries, or also
(with some limitations) just instrumented shared libraries and
non-instrumented binaries.

	Jakub


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