[RFC arm64] samples/bpf: explicitly exclude sysreg sections with asm macros
Mark Rutland
mark.rutland at arm.com
Fri Mar 17 10:17:44 PDT 2017
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.
More information about the linux-arm-kernel
mailing list