From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: "devel@uclibc-ng.org" <devel@uclibc-ng.org>,
Rich Felker <dalias@libc.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Arnd Bergmann <arnd@arndb.de>,
Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
lkml <linux-kernel@vger.kernel.org>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
Jin Yao <yao.jin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
arcml <linux-snps-arc@lists.infradead.org>
Subject: Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
Date: Thu, 2 May 2019 16:09:14 -0400 [thread overview]
Message-ID: <20190502200914.GA22982@kernel.org> (raw)
In-Reply-To: <596d2166-1952-a392-ef05-d3f59abf9fd0@synopsys.com>
Em Thu, May 02, 2019 at 09:55:26AM -0700, Vineet Gupta escreveu:
> 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 !
This is some remnant of the past, I'll check further but will end up
just ditching it altogether as you suggest :-)
[acme@quaco perf]$ find tools/ -type f | xargs grep HAVE_GLIBC_SUPPORT
tools/perf/builtin-version.c: STATUS(HAVE_GLIBC_SUPPORT, glibc);
tools/perf/Makefile.config: CFLAGS += -DHAVE_GLIBC_SUPPORT
[acme@quaco perf]$
Its just this case that ends up using that feature detection program,
[acme@quaco perf]$ vim tools/perf/Makefile.config
[acme@quaco perf]$ find tools/ -type f | xargs grep feature-glibc
tools/perf/Makefile.config: ifeq ($(feature-glibc), 1)
tools/perf/Makefile.config:ifeq ($(feature-glibc), 1)
[acme@quaco perf]$
BTW the function on it doesn't mean anything, what matters is if the
program builds or not :-)
- Arnaldo
WARNING: multiple messages have this Message-ID (diff)
From: acme@kernel.org (Arnaldo Carvalho de Melo)
To: linux-snps-arc@lists.infradead.org
Subject: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
Date: Thu, 2 May 2019 16:09:14 -0400 [thread overview]
Message-ID: <20190502200914.GA22982@kernel.org> (raw)
In-Reply-To: <596d2166-1952-a392-ef05-d3f59abf9fd0@synopsys.com>
Em Thu, May 02, 2019 at 09:55:26AM -0700, Vineet Gupta escreveu:
> 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 !
This is some remnant of the past, I'll check further but will end up
just ditching it altogether as you suggest :-)
[acme at quaco perf]$ find tools/ -type f | xargs grep HAVE_GLIBC_SUPPORT
tools/perf/builtin-version.c: STATUS(HAVE_GLIBC_SUPPORT, glibc);
tools/perf/Makefile.config: CFLAGS += -DHAVE_GLIBC_SUPPORT
[acme at quaco perf]$
Its just this case that ends up using that feature detection program,
[acme at quaco perf]$ vim tools/perf/Makefile.config
[acme at quaco perf]$ find tools/ -type f | xargs grep feature-glibc
tools/perf/Makefile.config: ifeq ($(feature-glibc), 1)
tools/perf/Makefile.config:ifeq ($(feature-glibc), 1)
[acme at quaco perf]$
BTW the function on it doesn't mean anything, what matters is if the
program builds or not :-)
- Arnaldo
WARNING: multiple messages have this Message-ID (diff)
From: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: Rich Felker <dalias@libc.org>, Jin Yao <yao.jin@linux.intel.com>,
Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
"devel@uclibc-ng.org" <devel@uclibc-ng.org>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
lkml <linux-kernel@vger.kernel.org>,
arcml <linux-snps-arc@lists.infradead.org>,
Arnd Bergmann <arnd@arndb.de>, Jiri Olsa <jolsa@kernel.org>,
Namhyung Kim <namhyung@kernel.org>
Subject: Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
Date: Thu, 2 May 2019 16:09:14 -0400 [thread overview]
Message-ID: <20190502200914.GA22982@kernel.org> (raw)
In-Reply-To: <596d2166-1952-a392-ef05-d3f59abf9fd0@synopsys.com>
Em Thu, May 02, 2019 at 09:55:26AM -0700, Vineet Gupta escreveu:
> 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 !
This is some remnant of the past, I'll check further but will end up
just ditching it altogether as you suggest :-)
[acme@quaco perf]$ find tools/ -type f | xargs grep HAVE_GLIBC_SUPPORT
tools/perf/builtin-version.c: STATUS(HAVE_GLIBC_SUPPORT, glibc);
tools/perf/Makefile.config: CFLAGS += -DHAVE_GLIBC_SUPPORT
[acme@quaco perf]$
Its just this case that ends up using that feature detection program,
[acme@quaco perf]$ vim tools/perf/Makefile.config
[acme@quaco perf]$ find tools/ -type f | xargs grep feature-glibc
tools/perf/Makefile.config: ifeq ($(feature-glibc), 1)
tools/perf/Makefile.config:ifeq ($(feature-glibc), 1)
[acme@quaco perf]$
BTW the function on it doesn't mean anything, what matters is if the
program builds or not :-)
- Arnaldo
next prev parent reply other threads:[~2019-05-02 20:09 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-19 23:32 perf tools build broken after v5.1-rc1 Vineet Gupta
2019-04-19 23:32 ` Vineet Gupta
2019-04-22 15:20 ` Arnaldo Carvalho de Melo
2019-04-22 15:20 ` Arnaldo Carvalho de Melo
2019-04-25 21:48 ` Arnaldo Carvalho de Melo
2019-04-25 21:48 ` Arnaldo Carvalho de Melo
2019-04-26 19:28 ` Arnaldo Carvalho de Melo
2019-04-26 19:28 ` Arnaldo Carvalho de Melo
2019-04-26 19:35 ` Arnaldo Carvalho de Melo
2019-04-26 19:35 ` Arnaldo Carvalho de Melo
2019-04-26 19:35 ` Arnaldo Carvalho de Melo
2019-04-29 17:23 ` Vineet Gupta
2019-04-29 17:23 ` Vineet Gupta
2019-05-03 5:58 ` [tip:perf/urgent] tools arch uapi: Copy missing unistd.h headers for arc, hexagon and riscv tip-bot for Arnaldo Carvalho de Melo
2019-04-29 17:14 ` perf tools build broken after v5.1-rc1 Vineet Gupta
2019-04-29 17:14 ` Vineet Gupta
2019-04-30 1:18 ` Arnaldo Carvalho de Melo
2019-04-30 1:18 ` Arnaldo Carvalho de Melo
2019-04-30 1:18 ` Arnaldo Carvalho de Melo
2019-04-30 15:53 ` Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1) Vineet Gupta
2019-04-30 15:53 ` Vineet Gupta
2019-04-30 17:04 ` Rich Felker
2019-04-30 17:04 ` Rich Felker
2019-04-30 17:13 ` Vineet Gupta
2019-04-30 17:13 ` Vineet Gupta
2019-05-01 3:12 ` Rich Felker
2019-05-01 3:12 ` Rich Felker
2019-05-02 16:55 ` Vineet Gupta
2019-05-02 16:55 ` Vineet Gupta
2019-05-02 16:55 ` Vineet Gupta
2019-05-02 20:09 ` Arnaldo Carvalho de Melo [this message]
2019-05-02 20:09 ` Arnaldo Carvalho de Melo
2019-05-02 20:09 ` Arnaldo Carvalho de Melo
2019-05-02 16:53 ` perf tools build broken after v5.1-rc1 Vineet Gupta
2019-05-02 16:53 ` Vineet Gupta
2019-04-29 17:17 ` Vineet Gupta
2019-04-29 17:17 ` Vineet Gupta
2019-04-30 16:12 ` Arnd Bergmann
2019-04-30 16:12 ` Arnd Bergmann
2019-05-01 20:41 ` Arnaldo Carvalho de Melo
2019-05-01 20:41 ` Arnaldo Carvalho de Melo
2019-05-01 21:17 ` Vineet Gupta
2019-05-01 21:17 ` Vineet Gupta
2019-05-02 14:36 ` Arnaldo Carvalho de Melo
2019-05-02 14:36 ` Arnaldo Carvalho de Melo
2019-05-02 14:36 ` Arnaldo Carvalho de Melo
2019-05-02 15:41 ` Arnaldo Carvalho de Melo
2019-05-02 15:41 ` Arnaldo Carvalho de Melo
2019-05-02 16:09 ` Vineet Gupta
2019-05-02 16:09 ` Vineet Gupta
2019-05-02 16:09 ` Vineet Gupta
2019-05-02 16:41 ` Arnaldo Carvalho de Melo
2019-05-02 16:41 ` Arnaldo Carvalho de Melo
2019-05-02 17:10 ` Vineet Gupta
2019-05-02 17:10 ` Vineet Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190502200914.GA22982@kernel.org \
--to=acme@kernel.org \
--cc=Vineet.Gupta1@synopsys.com \
--cc=acme@redhat.com \
--cc=arnaldo.melo@gmail.com \
--cc=arnd@arndb.de \
--cc=dalias@libc.org \
--cc=devel@uclibc-ng.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=namhyung@kernel.org \
--cc=yao.jin@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.