Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: perf test LLVM & clang 6 failing
To:     Matthias Kaehlcke <mka@chromium.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>
CC:     Arnaldo Carvalho de Melo <acme@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Wang Nan <wangnan0@huawei.com>,
        Alexei Starovoitov <alexei.starovoitov@gmail.com>,
        Adrian Hunter <adrian.hunter@intel.com>,
        David Ahern <dsahern@gmail.com>, Jiri Olsa <jolsa@kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andrey Ryabinin <aryabinin@virtuozzo.com>
References: <20171124144717.GO8789@kernel.org>
 <7cd16670-37c9-21f5-21c8-d50385ebc951@iogearbox.net>
 <20171127170435.GA3298@kernel.org>
 <7f618077-3a04-04b6-f6df-cf91d3ff4424@fb.com>
 <20171127193425.GC3298@kernel.org> <20171127195756.rbgduy5udx4cko2v@treble>
 <20171127214521.GB53228@google.com>
From:   Yonghong Song <yhs@fb.com>
Message-ID: <86934947-f267-4b36-be99-8f5f81faee4a@fb.com>
Date:   Mon, 27 Nov 2017 17:19:17 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171127214521.GB53228@google.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Received-SPF: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2017 01:19:20.6802 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9567b106-29a0-4b03-f5d5-08d535fe0e4a
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1830
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-28_01:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 11/27/17 1:45 PM, Matthias Kaehlcke wrote:
> El Mon, Nov 27, 2017 at 01:57:56PM -0600 Josh Poimboeuf ha dit:
> 
>> On Mon, Nov 27, 2017 at 04:34:25PM -0300, Arnaldo Carvalho de Melo wrote:
>>> Em Mon, Nov 27, 2017 at 11:11:56AM -0800, Yonghong Song escreveu:
>>>> On 11/27/17 9:04 AM, Arnaldo Carvalho de Melo wrote:
>>>>> Em Fri, Nov 24, 2017 at 04:16:52PM +0100, Daniel Borkmann escreveu:
>>>>>> [ +Yonghong ]
>>>>>
>>>>> + Josh
>>>>>> On 11/24/2017 03:47 PM, Arnaldo Carvalho de Melo wrote:
>>>>>>> FYI, just noticed, recently updated clang to version 6, from its
>>>>>>> upstream git repo.
>>>>>>
>>>>>> Do you recall what was your LLVM version prior to this where it was
>>>>>> working fine? (Wild guess from below would be the BPF inline asm
>>>>>> support that was added recently to LLVM (2865ab6996) vs asm() used
>>>>>> in headers included in the stdin header causing trouble due to arch
>>>>>> mixup?)
>>>>>
>>>>> So, if I go to the cset just before:
>>>>>
>>>>> commit f5caf621ee357279e759c0911daf6d55c7d36f03
>>>>> Author: Josh Poimboeuf <jpoimboe@redhat.com>
>>>>> Date:   Wed Sep 20 16:24:33 2017 -0500
>>>>>
>>>>>       x86/asm: Fix inline asm call constraints for Clang
>>>>> ---
>>>>>
>>>>> 'perf test LLVM' works again:
>>>>>
>>>>> [root@jouet ~]# perf test LLVM
>>>>> 37: LLVM search and compile                               :
>>>>> 37.1: Basic BPF llvm compile                              : Ok
>>>>> 37.2: kbuild searching                                    : Ok
>>>>> 37.3: Compile source for BPF prologue generation          : Ok
>>>>> 37.4: Compile source for BPF relocation                   : Ok
>>>>> [root@jouet ~]#
>>>>>
>>>>> I.e. 'perf test LLVM' built from what is in my acme/perf/urgent branch,
>>>>> targetted to v4.15, uses kernel headers and if I go to just before
>>>>> f5caf621ee, it works again, both with clang from fedora26 (4.0.1) and
>>>>> with 6.0, built from sources.
>>>>
>>>> This patch introduced a module level inline assembly.
>>>>
>>>> ...
>>>> --- a/arch/x86/include/asm/asm.h
>>>> +++ b/arch/x86/include/asm/asm.h
>>>> @@ -132,4 +132,15 @@
>>>>   /* For C file, we already have NOKPROBE_SYMBOL macro */
>>>>   #endif
>>>>
>>>> +#ifndef __ASSEMBLY__
>>>> +/*
>>>> + * This output constraint should be used for any inline asm which has a
>>>> "call"
>>>> + * instruction.  Otherwise the asm may be inserted before the frame pointer
>>>> + * gets set up by the containing function.  If you forget to do this,
>>>> objtool
>>>> + * may print a "call without frame pointer save/setup" warning.
>>>> + */
>>>> +register unsigned int __asm_call_sp asm("esp");
>>>> +#define ASM_CALL_CONSTRAINT "+r" (__asm_call_sp)
>>>> +#endif
>>>> ...
>>>>
>>>> This will cause "clang ... -target bpf ..." failure since 4.0 does not have
>>>> bpf inline asm support and 6.0 does not recognize the register 'esp'.
>>>
>>> Ok, explains the problem then, Josh, ideas on how to proceed here?
>>
>> The original change to add the global inline asm:
>>
>>    5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clang")
>>
>> was done to support clang in the first place.  Before that change, a
>> clang-built kernel didn't even boot.  So I'm a bit perplexed by the fact
>> that this change would be causing clang problems, since it was done to
>> fix clang in the first place.
>>
>> Adding Andrey and Matthias, maybe they can help clarify things.
> 
> Indeed the change was needed to boot on x86.
> 
> I know next to nothing about BPF, if I understand correctly the error
> is generated when compiling for the BPF "architecture" not for x86. In
> this process x86 assembly headers are included, one of which contains
> the declaration of the register variable, in an register that exists
> on x86, but not BPS.
> 
> I guess the first questions is whether the x86 asm headers should/need
> to be included when compiling for BPF. If this needed/can not be
> easily avoided one option could be to put the declaration within an
> ifdef __x86_64__ block.

There is a way to do this. You can use the similar mechanism to
the one in linux:samples/bpf and linux:tools/testing/selftests/bpf.

Basically, you first do:
   clang ... -O2 -emit-llvm -S prog.c <=== this uses x86_64 as the 
default target
   llc -march=bpf -filetype=obj prog.ll <=== this uses bpf target
This should work.

From 1585257315569877153@xxx Mon Nov 27 21:46:26 +0000 2017
X-GM-THRID: 1584959210990306928
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread