From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-73235-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 42239 invoked by alias); 12 Sep 2016 18:54:27 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 42227 invoked by uid 89); 12 Sep 2016 18:54:26 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=resending, Hx-languages-length:945, Large
X-HELO: mail-wm0-f46.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:cc;
        bh=CKBP4BLg6Ieyz8cJ9Nt+AhCnGRt5jN0P59zt/8ECQfc=;
        b=ZqwjdNHEUC0zNFFlCBuU2tY+vA6YzNla2nOxAggzRx14VJTdLFBRN2xFOIThgqlAd9
         gK8bkm53YFvnSzfeKYbXcshzhFQTEpkc/3wdW/wgZAxQrUQJHaHflxzzqFBuHB+vYRNm
         SN8qRnl20UMoVYzSClj1FZ8H4AJ+/gRJb5C/nGfSCpgvGxNkOtBqfTj7LcCdQJYQPnwd
         xQH2zfkpTxGUzKYugw/5xwaT2abrlLHQgesro8N18gqe9PazAdY+hma2Lj5TqBBqNr2m
         xjTaLvhCswJOgzEBnnkecfRvwA4LkK91nbogfHWY31G8tdZ2Y/j0gTKuTwhf/1Y5zJg/
         hyvw==
X-Gm-Message-State: AE9vXwNsjlEkc7TzHGxoFFiHgigYXGbV3fZF2Yuv99G2BmAWnYrOEROF5kk+VJPm+/o4Bb657y7Bpjo4C/MgS5nw
X-Received: by 10.28.103.133 with SMTP id b127mr1276414wmc.82.1473706463308;
 Mon, 12 Sep 2016 11:54:23 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <82777040-18f6-5686-5485-2ea338c74a4b@redhat.com>
References: <57CDAB08.8060601@samsung.com> <8d2403c8-466d-8f1a-e563-8b729deef9ce@redhat.com>
 <57CE8965.7050505@samsung.com> <CAN=P9phHJekS9DE9tqOfRLkccj7aOtVXqnpjcf1dFSsk52pu0A@mail.gmail.com>
 <82777040-18f6-5686-5485-2ea338c74a4b@redhat.com>
From: Kostya Serebryany <kcc@google.com>
Date: Mon, 12 Sep 2016 18:54:00 -0000
Message-ID: <CAN=P9pimm8EWqCrt9kn7PLYGH1_y+Kx+X=TuME6s-DAnZkaaEw@mail.gmail.com>
Subject: Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the
 same time.
To: Florian Weimer <fweimer@redhat.com>
Cc: Maxim Ostapenko <m.ostapenko@samsung.com>, GNU C Library <libc-alpha@sourceware.org>, 
	Yuri Gribov <tetra2005@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-SW-Source: 2016-09/txt/msg00211.txt.bz2

On Mon, Sep 12, 2016 at 2:30 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 09/10/2016 12:36 AM, Kostya Serebryany wrote:
>>>
>>> I thought we should compile everything except Glibc, no? Compiling Glibc
>>> with MSan would be tricky, that's why it needs interceptors.
>>
>>
>> Correct.
>
>
> Why?  Large parts of glibc are just another library and not that low-level.

[re-sending in plain text]
I don't say the current situation is ideal.
It is as it is because we simply can't build Glibc with clang and msan today.

>
> Sure, it is quite a bit of work to disentangle the low-level bits from those
> that can be instrumented, but so is writing correct interceptors which
> actually follow glibc behavior and are not merely approximation of the core
> functionality.  (I'm not talking about memset, but high-level things like
> getpwuid or glob.)
>
> Florian
>