linux-kernel - Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <596d2166-1952-a392-ef05-d3f59abf9fd0@synopsys.com>
Date:   Thu, 2 May 2019 09:55:26 -0700
From:   Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:     Rich Felker <dalias@...c.org>, Jin Yao <yao.jin@...ux.intel.com>
CC:     Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
        "devel@...ibc-ng.org" <devel@...ibc-ng.org>,
        "linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        lkml <linux-kernel@...r.kernel.org>,
        arcml <linux-snps-arc@...ts.infradead.org>,
        Arnd Bergmann <arnd@...db.de>, "Jiri Olsa" <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>
Subject: Re: Detecting libc in perf (was Re: perf tools build broken after
 v5.1-rc1)

On 4/30/19 8:12 PM, Rich Felker wrote:
>>> What are you trying to achieve? I was just CC'd and I'm missing the
>>> context.
>>
>> Sorry I added you as a subject matter expert but didn't provide enough context.
>>
>> The original issue [1] was perf failing to build on ARC due to perf tools needing
>> a copy of unistd.h but this thread [2] was a small side issue of auto-detecting
>> libc variaint in perf tools where despite uClibc tools, glibc is declared to be
>> detected, due to uClibc's historical hack of defining __GLIBC__. So __GLIBC__ is
>> not sufficient (and probably not the right interface to begin wtih) to ensure glibc.
>>
>> [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005676.html
>> [2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005684.html
> 
> I think you misunderstood -- 

:-)

> I'm asking what you're trying to achieve
> by detecting whether the libc is glibc, rather than whether it has
> some particular interface you want to conditionally use. This is a
> major smell and is usually something wrong that shouldn't be done.

Good question indeed. Back in 2015 I initially ran into some quirks due to subtle
libc differences.  At the time perf has a fwd ref for strlcpy which exactly
matched glibc but not uClibc.  see commit  a83d869f300bf91 "(perf tools: Elide
strlcpy warning with uclibc)" or 0215d59b154 "(tools lib: Reinstate strlcpy()
header guard with __UCLIBC__)"

But this still used the libc defined symbol __UCLIBC__ or __GLIBC__

Your question however pertains to perf glibc feature check where perf generates an
alternate symbol HAVE_GLIBC_SUPPORT.

This is dubious as first of all it detects glibc even for uClibc builds.

Even of we were to improve it, there seems to be no users of this symbol.

$git grep HAVE_GLIBC_SUPPORT
perf/Makefile.config:  CFLAGS += -DHAVE_GLIBC_SUPPORT
perf/builtin-version.c: STATUS(HAVE_GLIBC_SUPPORT, glibc)

So I'd propose to remove it !