Put -lasan always very early on the ld command line (PR sanitizer/55374)

Hi!

libasan relies on being linked before -lpthread, -lstdc++ and -lc, but so
far nothing was ensuring that.  Not only e.g. -lstdc++ could come before
-lasan when -lstdc++ was added by g++ language specific driver handling,
but also if the user specifies -lstdc++, -lpthread or -lc somewhere on
the gcc/g++ command line together with -fsanitize=address, those libraries
will likely be linked before -lasan.

This patch attempts to fix that, by (for Linux) linking -lasan as early as
possible, in particularly after -L.../ options, but before the user command
line options (input files, -Wl,* options, etc.) are copied over to the
command line (%o spec file hunk).  For -static-libasan, the patch changes
it to link -lasan only when linking executables (and PIEs), but when
linking shared libraries, we don't want to duplicate the libasan stuff in
each shared library.  And, when libasan.a is linked into executables/PIEs,
it is linked with -Bstatic --whole-archive -lasan --no-whole-archive -Bdynamic 
to avoid issues with portions of libasan.a being linked at various spots
on the command line, when it comes first, nothing would actually link it in,
and when we'd prepend it before every -lpthread, -lstdc++ and -lc on the
command line, it would be very hard to get it right (e.g. due to -Wl,-B*
user options).

This reveals that two tests don't pass with -lasan being linked before
-lstdc++, one fixed by backporting fix from upstream, the other by adjusting
the output regexp.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2013-01-22  Jakub Jelinek  <jakub@redhat.com>

	PR sanitizer/55374
	* gcc.c (LIBASAN_SPEC): Define just to ADD_STATIC_LIBASAN_LIBS if
	LIBASAN_EARLY_SPEC is defined.
	(LIBASAN_EARLY_SPEC): Define to empty string if not already defined.
	(LINK_COMMAND_SPEC): Add LIBASAN_EARLY_SPEC for -fsanitize=address,
	before %o.
	* config/gnu-user.h (LIBASAN_EARLY_SPEC): Define.

	* g++.dg/asan/large-func-test-1.C: Allow both _Zna[jm] in addition
	to _Znw[jm] in the backtrace.  Allow _Zna[jm] to be the first frame
	printed in backtrace.
	* g++.dg/asan/deep-stack-uaf-1.C: Use malloc instead of operator new
	to avoid errors about mismatched allocation vs. deallocation.


	Jakub

Looks good to me.  OK if nobody else responds today.

Jason

Jakub Jelinek <jakub@redhat.com> writes:


> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2013-01-22  Jakub Jelinek  <jakub@redhat.com>
>
> 	PR sanitizer/55374
> 	* gcc.c (LIBASAN_SPEC): Define just to ADD_STATIC_LIBASAN_LIBS if
> 	LIBASAN_EARLY_SPEC is defined.
> 	(LIBASAN_EARLY_SPEC): Define to empty string if not already defined.
> 	(LINK_COMMAND_SPEC): Add LIBASAN_EARLY_SPEC for -fsanitize=address,
> 	before %o.
> 	* config/gnu-user.h (LIBASAN_EARLY_SPEC): Define.
>
> 	* g++.dg/asan/large-func-test-1.C: Allow both _Zna[jm] in addition
> 	to _Znw[jm] in the backtrace.  Allow _Zna[jm] to be the first frame
> 	printed in backtrace.
> 	* g++.dg/asan/deep-stack-uaf-1.C: Use malloc instead of operator new
> 	to avoid errors about mismatched allocation vs. deallocation.

This looks okay for me.  Sorry for the delay.

As an aside, I am curious why about ...

> --- gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C.jj	2012-12-14 16:24:38.000000000 +0100
> +++ gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C	2013-01-22 16:43:03.337091101 +0100
> @@ -27,7 +27,7 @@ struct DeepFree<0> {
>  };
>  
>  int main() {
> -  char *x = new char[10];
> +  char *x = (char*)malloc(10);
>    // deep_free(x);
>    DeepFree<200>::free(x);
>    return x[5];

... why/how this is falling when -lasan comes before -lstdc++?

On Wed, Jan 30, 2013 at 04:04:55PM +0100, Dodji Seketeli wrote:
> As an aside, I am curious why about ...
> 
> > --- gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C.jj	2012-12-14 16:24:38.000000000 +0100
> > +++ gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C	2013-01-22 16:43:03.337091101 +0100
> > @@ -27,7 +27,7 @@ struct DeepFree<0> {
> >  };
> >  
> >  int main() {
> > -  char *x = new char[10];
> > +  char *x = (char*)malloc(10);
> >    // deep_free(x);
> >    DeepFree<200>::free(x);
> >    return x[5];
> 
> ... why/how this is falling when -lasan comes before -lstdc++?

libasan has added recently support for operator new and operator new[]
checking, which checks that there is not a mismatch between the way
how object is allocated (malloc/calloc/realloc vs. operator new vs. operator
new[]) and how it is deallocated (free vs. delete vs. delete[]).  The
deep-stack-uaf-1.C testcase has been violating this (new char[10]
allocation, free (x) deallocation) and has been changed upstream
when those changes landed into libasan.  When -lstdc++ came first,
the -lasan operator new interceptor wasn't called (because libstdc++'s
operator new was earlier in search scope) and thus it appeared as calling
malloc and doing free to -lasan.

	Jakub