From: Mark Brown <broonie@kernel.org>
To: Dave P Martin <Dave.Martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
linux-arm-kernel@lists.infradead.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 1/4] kselftest/arm64: Provide a helper binary and "library" for SVE RDVL
Date: Thu, 29 Jul 2021 17:03:34 +0100 [thread overview]
Message-ID: <20210729160334.GQ4670@sirena.org.uk> (raw)
In-Reply-To: <20210729132701.GH20179@e103592.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]
On Thu, Jul 29, 2021 at 02:27:04PM +0100, Dave P Martin wrote:
> On Thu, Jul 29, 2021 at 12:22:17PM +0100, Mark Brown wrote:
> > Yeah, it doesn't seem to be in the slightest bit idiomatic for the arm64
> > asm code the kernel has. I don't know if you think it's worth adding
> > that to SYM_FUNC_START now we have it though?
> Actually, I think the core definition of SYM_FUNC_END() in
> <linux/linkage.h> does this.
Ah, so it does.
> It would be good to pick up the common linkage macros; if we have to
> sprinkle .type manually all over the tests people will likely make
> mistakes, to that's probably not worth it.
> If picking up the macros isn't trivial to do, I guess it's not that
> important at this stage.
They're not exported from the kernel at all at the minute so that'd be a
whole new block of work that feels out of scope here, we already have a
stack of asm code in selftests.
> > that those are outside the kernel either. We will have to do something
> > like that if anyone starts building userspace with BTI though (or I
> > might just shove a BTI C in there unconditionally, I'm sure we'll cope
> > with the overhead on older systems).
> I thought about that, but that .S file isn't annotated as supporting
> BTI, so I guess there's no problem for now(?)
True, we'll generate linker warnings but it should otherwise sort itself
out unless someone forced BTI mode. The whole annotation thing really
isn't fun to deal with for assembly code, hopefully there'll be some
toolchain improvements in this area at some point.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Dave P Martin <Dave.Martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
linux-arm-kernel@lists.infradead.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 1/4] kselftest/arm64: Provide a helper binary and "library" for SVE RDVL
Date: Thu, 29 Jul 2021 17:03:34 +0100 [thread overview]
Message-ID: <20210729160334.GQ4670@sirena.org.uk> (raw)
In-Reply-To: <20210729132701.GH20179@e103592.cambridge.arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1549 bytes --]
On Thu, Jul 29, 2021 at 02:27:04PM +0100, Dave P Martin wrote:
> On Thu, Jul 29, 2021 at 12:22:17PM +0100, Mark Brown wrote:
> > Yeah, it doesn't seem to be in the slightest bit idiomatic for the arm64
> > asm code the kernel has. I don't know if you think it's worth adding
> > that to SYM_FUNC_START now we have it though?
> Actually, I think the core definition of SYM_FUNC_END() in
> <linux/linkage.h> does this.
Ah, so it does.
> It would be good to pick up the common linkage macros; if we have to
> sprinkle .type manually all over the tests people will likely make
> mistakes, to that's probably not worth it.
> If picking up the macros isn't trivial to do, I guess it's not that
> important at this stage.
They're not exported from the kernel at all at the minute so that'd be a
whole new block of work that feels out of scope here, we already have a
stack of asm code in selftests.
> > that those are outside the kernel either. We will have to do something
> > like that if anyone starts building userspace with BTI though (or I
> > might just shove a BTI C in there unconditionally, I'm sure we'll cope
> > with the overhead on older systems).
> I thought about that, but that .S file isn't annotated as supporting
> BTI, so I guess there's no problem for now(?)
True, we'll generate linker warnings but it should otherwise sort itself
out unless someone forced BTI mode. The whole annotation thing really
isn't fun to deal with for assembly code, hopefully there'll be some
toolchain improvements in this area at some point.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-07-29 16:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-28 16:33 [PATCH v2 0/4] kselftest/arm64: Vector length configuration tests Mark Brown
2021-07-28 16:33 ` Mark Brown
2021-07-28 16:33 ` [PATCH v2 1/4] kselftest/arm64: Provide a helper binary and "library" for SVE RDVL Mark Brown
2021-07-28 16:33 ` Mark Brown
2021-07-29 9:52 ` Dave Martin
2021-07-29 9:52 ` Dave Martin
2021-07-29 11:22 ` Mark Brown
2021-07-29 11:22 ` Mark Brown
2021-07-29 13:27 ` Dave P Martin
2021-07-29 13:27 ` Dave P Martin
2021-07-29 16:03 ` Mark Brown [this message]
2021-07-29 16:03 ` Mark Brown
2021-07-29 16:17 ` Dave Martin
2021-07-29 16:17 ` Dave Martin
2021-07-28 16:33 ` [PATCH v2 2/4] kselftest/arm64: Validate vector lengths are set in sve-probe-vls Mark Brown
2021-07-28 16:33 ` Mark Brown
2021-07-29 9:52 ` Dave Martin
2021-07-29 9:52 ` Dave Martin
2021-07-28 16:33 ` [PATCH v2 3/4] kselftest/arm64: Add tests for SVE vector configuration Mark Brown
2021-07-28 16:33 ` Mark Brown
2021-07-29 9:52 ` Dave Martin
2021-07-29 9:52 ` Dave Martin
2021-07-28 16:33 ` [PATCH v2 4/4] kselftest/arm64: Add a TODO list for floating point tests Mark Brown
2021-07-28 16:33 ` Mark Brown
2021-07-29 9:52 ` Dave Martin
2021-07-29 9:52 ` Dave Martin
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=20210729160334.GQ4670@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Dave.Martin@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.