linux-kernel - Re: [PATCH 34/34] perf tools unwinding: Use the per-feature check flags

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 7 Dec 2013 11:17:02 +0100
From:	Jean Pihet <jean.pihet@...aro.org>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Will Deacon <will.deacon@....com>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	Patch Tracking <patches@...aro.org>
Subject: Re: [PATCH 34/34] perf tools unwinding: Use the per-feature check flags

Hi,

On 3 December 2013 17:15, Jean Pihet <jean.pihet@...aro.org> wrote:
> I just resent the patches as v2.
>
> I tested on x86_64, ARMv7 and ARMv8 with and without LIBUNWIND_DIR=
> set in 'make -C tools/perf'. Can you check on your build setup?
I just found that the linker options may not work on some distros (in
my case Ubuntu on ARMv7). The fix is here below.
v3 is on its way.

Can you please check?

diff --git a/tools/perf/config/feature-checks/Makefile
b/tools/perf/config/feature-checks/Makefile
index 87e7900..0bf3af7 100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@ -33,7 +33,7 @@ CC := $(CC) -MD

 all: $(FILES)

-BUILD = $(CC) $(CFLAGS) $(LDFLAGS) -o $(OUTPUT)$@ $@.c
+BUILD = $(CC) $(CFLAGS) -o $(OUTPUT)$@ $@.c $(LDFLAGS)

 ###############################



Thanks,
Jean

>
> On 29 November 2013 16:45, Jiri Olsa <jolsa@...hat.com> wrote:
>> On Thu, Nov 28, 2013 at 09:02:23PM +0100, Jean Pihet wrote:
>>> On 28 November 2013 14:46, Arnaldo Carvalho de Melo <acme@...radead.org> wrote:
>>> > Em Thu, Nov 28, 2013 at 09:56:19AM -0300, Arnaldo Carvalho de Melo escreveu:
>>> >> Em Thu, Nov 28, 2013 at 10:58:01AM +0100, Jiri Olsa escreveu:
>>> >> > On Wed, Nov 27, 2013 at 11:43:23PM +0100, Jiri Olsa wrote:
>>> >> > > On Wed, Nov 27, 2013 at 05:16:34PM -0300, Arnaldo Carvalho de Melo wrote:
>>> >> > >   LINK     perf
>>> >> > > /bin/ld: cannot find -lunwind
>>> >> > > /bin/ld: cannot find -lunwind-x86_64
>>> >> > > collect2: error: ld returned 1 exit status
>>> >> > > make[1]: *** [perf] Error 1
>>> >> > > make[1]: *** Waiting for unfinished jobs....
>>> >> > > make: *** [all] Error 2
>>> >>
>>> >> > > I haven't checked this one.. will do tomorrow
>>> >>
>>> >> > we need to plug libunwind flags/libs only if
>>> >> > the $(feature-libunwind) is enabled..
>>> >>
>>> >> > NO_LIBUNWIND - user's decision not to link with libunwind or
>>> >> >                architecture that does not support it
>>> >>
>>> >> > $(feature-libunwind) - if it's actually installed
>>> >>
>>> >> > attached change fixies that for me, feel free to use/merge it
>>> >>
>>> >> Argh, I used tests/make on one machine where those two patches by Jean
>>> >> were not applied, then rebased on another, the one I use to submit,
>>> >> those got included but not tests/make tested, which probably explains
>>> >> why this got thru :-\
>>> >>
>>> >> Jean, can you please check that this works for you on ARM too?
>>> >
>>> > I just noticed that this patch breaks the feature detection mechanism,
>>> > after it is applied it is back performing all tests at every make call,
>>> > this needs rethinking, so I'm dropping both.
>>> Oh I am sorry about that. I tested on ARM with and without the
>>> LIBUNWIND_DIR option set.
>>> Let me rethink/rework this and come back to you with a proper fix.
>>>
>>> >
>>> > Ingo, please disregard, yet again, my latest pull request, sigh.
>>> >
>>> > Jiri, this could be something for tests/make, till then I'll try
>>> > to check this manually.
>>>
>>> One question though: are you OK with the principle of having
>>> per-feature check flags? This brings two things to the feature
>>> detection and build:
>>> 1. the ability to specify specific flags for the feature check, which
>>> is not possible on the current code,
>>> 2. a simplification in the Makefiles.
>>
>> looks good to me
>>
>> jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/