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;
To:     <acme@redhat.com>
CC:     Alexei Starovoitov <ast@fb.com>,
        Daniel Borkmann <daniel@iogearbox.net>,
        David Miller <davem@davemloft.net>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
From:   Yonghong Song <yhs@fb.com>
Subject: bpf: handling non BPF register names in inline assembly with -target
 bpf
Message-ID: <c8b0b3c0-6687-1be2-66d0-95b20662145d@fb.com>
Date:   Wed, 11 Apr 2018 09:37:46 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
 Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
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: 11 Apr 2018 16:37:50.2828 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 03f1c328-1034-4577-b77d-08d59fca9163
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR15MB0073
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-04-11_07:,,
 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

Hi, Arnaldo,

When I studied the bpf compilation issue with latest linus/net-next 
kernel (https://patchwork.kernel.org/patch/10333829/), an alternative
approach I tried is to use __BPF__ macro. The following patch
introduced "#ifndef __BPF__" in arch/x86/include/asm/asm.h for
some inline assembly related to x86 "esp" register name.

==========
  commit ca26cffa4e4aaeb09bb9e308f95c7835cb149248
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Dec 4 13:08:47 2017 -0300

     x86/asm: Allow again using asm.h when building for the 'bpf' clang 
target

     Up to f5caf621ee35 ("x86/asm: Fix inline asm call constraints for 
Clang")
     we were able to use x86 headers to build to the 'bpf' clang target, as
     done by the BPF code in tools/perf/.
  ...
diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
index 219faae..386a690 100644
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -136,6 +136,7 @@
  #endif

  #ifndef __ASSEMBLY__
+#ifndef __BPF__
  /*
   * 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
@@ -145,5 +146,6 @@
  register unsigned long current_stack_pointer asm(_ASM_SP);
  #define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer)
  #endif
+#endif
...
==========

I just landed a clang patch (clang 7.0.0 trunk)
https://reviews.llvm.org/rL329823
which will permit bpf clang target to accept ANY register
names. In this case, the inline assembly will be accepted by clang
and will be thrown away since variable current_stack_pointer is
not used in bpf programs.

If the inline assembly is indeed for BPF program, later llc AsmParser 
will do syntax and semantics checking again.

With the above clang patch, the above "#ifndef __BPF__" can be removed.
You can decide when is the appropriate time to use latest clang compiler
and remove the above "#ifndef __BPF__".

Thanks!

Yonghong