public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC arm64] samples/bpf: explicitly exclude sysreg sections with asm macros
Date: Thu, 16 Mar 2017 10:42:04 +0000	[thread overview]
Message-ID: <20170316104204.GA31101@leverpostej> (raw)
In-Reply-To: <20170315205404.GA43995@C02RW35GFVH8.dhcp.broadcom.net>

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:
> > > > On Fri, Mar 10, 2017 at 02:26:56PM -0500, Andy Gospodarek wrote:
> > > > > On Fri, Mar 10, 2017 at 05:52:30PM +0000, Will Deacon wrote:
 
> > > > > It isn't the ASM itself that causes the compilation to fail, it's the
> > > > > ASM macros included inside the new ifdef that are problematic.  Here is
> > > > > what is seen per object file:
> > > > 
> > > > > ./arch/arm64/include/asm/barrier.h:62:23: note: expanded from macro
> > > > > '__smp_store_release'
> > > > >                 asm volatile ("stlr %1, %0"
> > > > > \
> > > > >                                     ^
> > > > > 1 warning generated.
> > > > > LLVM ERROR: Inline asm not supported by this streamer because we don't  <----  THIS LINE
> > > > > have an asm parser for this target
> > > > 
> > > > ... so as far as I can see it's the presence of any inline assembly that
> > > > the tool cannot handle, as LLVM tells us.

> > In the error message, LLVM explicitly states that it does not have a
> > parser for this target's assembly -- which would be a problem for *any*
> > inline assembly.
> > 
> > How does that specific error relate to the use of assembly macros within
> > sysreg.h?
> 
> This is the only error that is relevant:
> 
> 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. 

Indeed; as Will and I stated previously.

> Is this the only inline assembly outside a function that is not inside
> #ifdef __ASSEMBLY__ in the arm64 tree?

An __ASSEMBLY__ guard is irrelevant. We need the compiler to handle the
asm() statement, not the assembler (which cannot even parse it).

The kernel uses asm statements outside of functions elsewhere. For
example, take a look in <linux/export.h>. See that EXPORT_SYMBOL() uses
__CRC_SYMBOL(), which uses asm statements. The EXPORT_SYMBOL() is used
outside of functions, on all architectures, arm64 and x86 included.

I don't see why being inside a function matters. Given the error
message, the toolchain presumably can't parse inline assembly in any
context. We have static inline functions with assembly in headers, which
are presumably affected.

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.

Thanks,
Mark.

  reply	other threads:[~2017-03-16 10:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-09 23:18 [RFC arm64] samples/bpf: explicitly exclude sysreg sections with asm macros Andy Gospodarek
2017-03-10 17:52 ` Will Deacon
2017-03-10 19:26   ` Andy Gospodarek
2017-03-10 20:41     ` Mark Rutland
2017-03-15 18:31       ` Andy Gospodarek
2017-03-15 19:17         ` Mark Rutland
2017-03-15 20:54           ` Andy Gospodarek
2017-03-16 10:42             ` Mark Rutland [this message]
2017-03-16 21:04               ` Andy Gospodarek
2017-03-17 11:11                 ` Robin Murphy
2017-03-17 13:58                   ` Andy Gospodarek
2017-03-17 16:57                     ` Robin Murphy
2017-03-17 17:04                       ` Mark Rutland
2017-03-17 17:43                       ` Andy Gospodarek
2017-03-17 17:17                 ` Mark Rutland
2017-03-10 18:13 ` Mark Rutland
2017-03-10 19:35   ` Andy Gospodarek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170316104204.GA31101@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox