[PATCH] [LLVM] [sanitizer] add conditionals for libc

Kostya Serebryany kcc at google.com
Wed Apr 23 03:45:21 PDT 2014

On Wed, Apr 23, 2014 at 2:38 PM, Bernhard Reutner-Fischer <
rep.dot.nop at gmail.com> wrote:

> On 23 April 2014 10:57, Kostya Serebryany <kcc at google.com> wrote:
> > The patch is huge and has too many ifdefs.
> > It will have some time for us to review and will be very costly to
> maintain.
> Why do you think it will be very costly to maintain?

My assertion is based on experience.

> These things (e.g. glob_t members) do not change between glibc-releases, so
> i fail to see how this would be costly to maintain? It's pretty much a
> one-time
> thing to do IMO.
> > So, before we continue with review I would like to hear the motivation
> and
> The motivation behind this patch is that there are libc's apart from
> glibc, and
> these libc implementations, being POSIX compliant, may lack certain GNU
> extensions (as implemented in glibc). As you can see in your own code, you
> have gazillions of conditionals (preprocessor conditionals, which i add
> just add
> a couple of more, generic ones, btw, to answer your comment from above) to
> handle these other libc's.

Ok. What particular libc implementation are you trying to use?
And what particular tool are you trying to use (asan, tsan, msan)?
Most of the things you hide under ifdefs are important only/mostly for
msan, which does not exist in the GCC variant anyway.

> The route this patch takes it to probe these non-standard things and
> act accordingly.
> > whether you are welling to help us maintain this code in future (= set
> up a public build bot)
> I'm certainly willing to help maintain this code in the future since i
> want to use
> your nice sanitizers via gcc, sure. I cannot, however, setup a public
> build-bot since
> my notebook is not prepared to handle this task on a regular basis.
> If you break stuff upstream and i find the backported gcc version to
> be dysfunctional, i
> will send you fixes if time permits.

This round trip has very long latency and brings heavy burden on us (code
We are very reluctant to pay this price.
Having a public bot for llvm upstream code will reduce this cost.

> I think the patch itself is pretty straight forward,

It is straight forward, but it is also huge.
Depending on your actual needs (see above) we might be able to do something
*much* simpler.


> please let me
> know if you have specific
> questions about a technical aspect of the patch.
> Please apply.
> thanks,
> >
> > http://reviews.llvm.org/D3464
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140423/9f6025ee/attachment.html>

More information about the llvm-commits mailing list