On Mon, Nov 26, 2012 at 12:17:44PM +0400, Dmitry Vyukov wrote:
> On Sat, Nov 24, 2012 at 12:58 PM, Dmitry Vyukov <dvyu...@google.com> wrote:
> >>> Ok. A slight problem then is that where the tsan pass sits right now,
> >>> there
> >>> is no easy way to find out if the builtin call will be expanded inline or
> >>> not, so (similar for asan), if we instrument them in the pass, it might be
> >>> instrumented twice at runtime if the builtin is expanded as a library call
> >>> (once the added instrumentation for the builtin, once in the intercepted
> >>> library call). That isn't wrong, just might need slightly more resources
> >>> than if we ensured we only instrument the builtin if it isn't expanded
> >>> inline.
> >>>
> >>
> >> Should inlining of those functions be disabled as if -fno-builtins is
> >> specified?
> >
> > Yes, it sounds reasonable. Performance characteristics under tsan
> > differ significantly, so most likely we don't care.
>
>
> Do we still need range access functions then?
Yes. I think whether to instrument builtins inline or not should be a user
decision, -fsanitize-thread and either nothinng or -fno-builtin. Implying
-fno-builtin might penalize some code unnecessarily (remember, builtin
handling is not only about expanding some builtins inline, but also about
folding them if they are used with constant arguments, performing all sorts
of optimizations etc., all of which are ok, just we don't have a knob to
disable inline expansion of some builtins (which, some are certainly ok,
e.g. those that don't have a library counterpart).
Also note that many programs use __builtin_* calls directly and then you
can't disable recognizing them as builtins.
Jakub
