On Tue, Jun 18, 2013 at 10:45:53PM +0000, Joseph S. Myers wrote:
> On Tue, 18 Jun 2013, Jakub Jelinek wrote:
>
> > On Tue, Jun 18, 2013 at 04:42:51PM +0200, Marek Polacek wrote:
> > > Ok, should be done now (together with other nit-fixes).
> > > Regtested/bootstrapped on x86_64-linux, ok for trunk?
> >
> > Looks good to me, the only thing I'm worried about are how this
> > interferes with the
> > %{fsanitize=address:...}
> > and
> > %{fsanitize=thread:...}
> > bits in gcc.c. Because we should link in -lasan even for
> > -fsanitize=shift,address,undefined
> > and should not link in -lasan for
> > -fsanitize=address -fno-sanitize=undefined,address,shift
> > (generally, what we have guarded right now with
> > %{fsanitize=address:...}
> > should be done if flag_sanitize & SANITIZE_ADDRESS is going to be
> > true in the end, etc., and we'll need to link in
> > -lubsan whenever at least one of the undefined options are set in the
> > bitmask. -lubsan isn't incompatible with -lasan nor -ltsan, but -lasan
> > and -ltsan are incompatible.
> >
> > Joseph, any thoughts how to deal with this?
>
> Try defining a new spec function or functions that uses flag_sanitize to
> determine what linker arguments to pass? Since the option handling is in
> opts.c it should get run in the driver so flag_sanitize should be set
> correctly there; as long as the specs in question run after the relevant
> option processing, a spec function should work for this.
While it would be possible to define say %:sanitize(thread LIBTSAN_EARLY)
that would work roughly like %{fsanitize=thread:LIBTSAN_EARLY} worked
until now (variable number of arguments that would be concatenated together
if flag_sanitize & ..., otherwise return empty), we use e.g. %e inside
of the %{fsanitize=thread:...} etc.
So, I wonder if we couldn't extend the handle_braces, I think right now
empty atoms are disallowed for the first choice, so perhaps
%{%:function(args):...}
where %:function(args) would be expanded to either non-empty or empty string
and depending on that the condition would be then true resp. false.
As % is not considered part of the atom name, and we require after atom name
optional * and then only one of |, }, &, :, I think this wouldn't be
ambiguous in the grammar.
We could then have:
%{!%:function1():-lfoo;%:function2(bar baz):-lbar -lbaz;-lxxx}
and for the sanitizer purposes:
%{%:sanitize(address):LIBTSAN_EARLY}
%{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):" LIBASAN_SPEC "\
%{static:%ecannot specify -static with -fsanitize=address}\
%{%:sanitize(thread):%e-fsanitize=address is incompatible with
-fsanitize=thread}}\
%{%:sanitize(thread):" LIBTSAN_SPEC "\
%{!pie:%{!shared:%e-fsanitize=thread linking must be done with -pie or
%-shared}}}}}"
Jakub
