[RFC arm64] samples/bpf: explicitly exclude sysreg sections with asm macros

[Mark Rutland]

On Thu, Mar 16, 2017 at 05:04:55PM -0400, Andy Gospodarek wrote:
> On Thu, Mar 16, 2017 at 10:42:04AM +0000, Mark Rutland wrote:
> > On Wed, Mar 15, 2017 at 04:54:04PM -0400, Andy Gospodarek wrote:
> > > On Wed, Mar 15, 2017 at 07:17:41PM +0000, Mark Rutland wrote:
> > > > On Wed, Mar 15, 2017 at 02:31:30PM -0400, Andy Gospodarek wrote:
> > > > > On Fri, Mar 10, 2017 at 08:41:13PM +0000, Mark Rutland wrote:

> > > > > > ... so as far as I can see it's the presence of any inline assembly that
> > > > > > the tool cannot handle, as LLVM tells us.

> > > LLVM ERROR: Inline asm not supported by this streamer because we
> > > don't have an asm parser for this target
> > > 
> > > Upon inspection it does not appear that this is explicitly related to
> > > assembly macros, just simple inline assembly. 

> You are correct that it appears llvm cannot process any inline asm for
> arm64.  Sadly (or luckily) the inability to process this is not a
> hard-requirement for llvm to properly compile code that includes these
> h-files -- as long as none of #defines/c-macros/inline functions are
> actually *called* in the code I'm trying to compile.

The Linux-internal arm64 headers are there to build the kernel using a
supported toolchain. From my PoV, if you want to use the Linux-internal
arm64 headers, you need to be compatible with the toolchain(s) that we
target. 

I would imagine the x86 developers would have a similar feeling, were
this issue to crop up on x86.

> Sorry I continue to harp on this, but I've been testing XDP on ARM64
> using some Broadcom SoCs and I'm seeing some really nice performance
> benefits to being able to process so many frames per second using a
> smaller footprint device.  I'd like to see the ARM64 XDP user community
> grow, but without the ability to easily compile the samples in the
> upstream kernel tree today I just don't see this user- or developer-base
> growing.  

Please talk to the LLVM community, and see what is necessary in order to
make it compatible with the toolchains we support.

> > It sounds like the toolchain you are using is lacking in functionality
> > that is presumably present when targeting x86, or the error messages are
> > simply misleading. In either case, there's a toolchain issue to be
> > addressed, and not a kernel issue.
> 
> While I generally agree isn't the entire reason this inline asm exists
> -- to fix a binutils issue?  :-)
> 
> commit 72c5839515260dce966cd24f54436e6583288e6c
> Author: Catalin Marinas <catalin.marinas at arm.com>
> Date:   Thu Jul 24 14:14:42 2014 +0100
> 
>     arm64: gicv3: Allow GICv3 compilation with older binutils

We introduced this code so as to *retain* compatibility with a toolchain
that we explicitly supported, but accidentally broke with the addition
of the GICv3 code.

We have clearly never supoprted a toolchain that cannot parse inline
asembly.

Thanks,
Mark.