All of lore.kernel.org
 help / color / mirror / Atom feed
From: kevin.brodsky@arm.com (Kevin Brodsky)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 4/8] arm64: compat: Add a 32-bit vDSO
Date: Thu, 1 Dec 2016 14:27:40 +0000	[thread overview]
Message-ID: <70668250-d51b-a879-8ebf-66a07c178718@arm.com> (raw)
In-Reply-To: <20161121184414.GC28723@e104818-lin.cambridge.arm.com>

On 21/11/16 18:44, Catalin Marinas wrote:
> On Mon, Nov 21, 2016 at 03:45:55PM +0000, Kevin Brodsky wrote:
>> On 04/11/16 20:03, Catalin Marinas wrote:
>>> On Fri, Oct 28, 2016 at 11:20:07AM +0100, Kevin Brodsky wrote:
>>>> On 28/10/16 04:09, Jisheng Zhang wrote:
>>>>> On Thu, 27 Oct 2016 17:30:54 +0100 Kevin Brodsky wrote:
>>>>>> +# Force -O2 to avoid libgcc dependencies
>>>>>> +VDSO_CFLAGS := -march=armv8-a -O2
>>>>> For completeness, bringing 32bit compiler need to check whether the 32bit
>>>>> toolchain support some options. IIRC, armv8-a support isn't enabled until
>>>>> gcc 4.8, so old toolchains such gcc-4.7 will complain:
>>>>>    error: unrecognized argument in option ?-march=armv8-a?
>>>> That's a fair point. I guess -march=armv8-a is not strictly necessary and
>>>> the produced vDSO should be fine if arch/arm/vdso also compiles fine.
>>>> However we would still need to pass -march=armv7-a. I'm not sure what to do
>>>> between:
>>>> * Checking that the compiler supports -march=armv8-a when inspecting
>>>> CROSS_COMPILE_ARM32, and if it doesn't vdso32 will not be built.
>>>> * Checking whether -march=armv8-a is available here, and if it is not fall
>>>> back to -march=armv7-a.
>>> Does v8 vs v7 make any difference in the generated code? If not, we
>>> could just stick to armv7-a permanently.
>> I've just tried compiling with -march=armv7-a, and in fact it doesn't
>> compile at all. It turns out vgettimeofday.c uses smp_rmb(), which expands
>> to dmb ishld on arm64, and ishld doesn't exist in ARMv7. We could possibly
>> work around that, but I think requiring GCC 4.8 is reasonable.
> Since vgettimeofday.c is meant to be compiled for AArch32, it wouldn't
> look too bad to define its own barriers rather than relying on the
> AArch64 ones. So you could define v7_smp_rmb/v7_smp_wmb and use them in
> this file. Alternatively, replace smp_rmb() with smp_mb() in this file
> but with a big comment about ARMv7 compilation requirement and "ishld"
> not being available.

Fair enough. I'll add AArch32 barrier macros and compile with -march=armv7-a if the 
compiler doesn't support armv8-a. It's true that using arm64 barrier macros in 32-bit 
code is a bit dodgy anyway.

Cheers,
Kevin

  reply	other threads:[~2016-12-01 14:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-27 16:30 [RFC PATCH v2 0/8] arm64: Add a compat vDSO Kevin Brodsky
2016-10-27 16:30 ` [RFC PATCH v2 1/8] arm64: Refactor vDSO setup Kevin Brodsky
2016-10-27 16:30 ` [RFC PATCH v2 2/8] arm64: compat: Add time-related syscall numbers Kevin Brodsky
2016-10-27 16:30 ` [RFC PATCH v2 3/8] arm64: compat: Expose offset to registers in sigframes Kevin Brodsky
2016-10-27 16:30 ` [RFC PATCH v2 4/8] arm64: compat: Add a 32-bit vDSO Kevin Brodsky
2016-10-28  3:09   ` Jisheng Zhang
2016-10-28 10:20     ` Kevin Brodsky
2016-11-04 20:03       ` Catalin Marinas
2016-11-21 15:45         ` Kevin Brodsky
2016-11-21 18:44           ` Catalin Marinas
2016-12-01 14:27             ` Kevin Brodsky [this message]
2016-10-27 16:30 ` [RFC PATCH v2 5/8] arm64: compat: 32-bit vDSO setup Kevin Brodsky
2016-10-27 16:30 ` [RFC PATCH v2 6/8] arm64: elf: Set AT_SYSINFO_EHDR in compat processes Kevin Brodsky
2016-10-27 16:30 ` [RFC PATCH v2 7/8] arm64: compat: Use vDSO sigreturn trampolines if available Kevin Brodsky
2016-10-27 16:30 ` [RFC PATCH v2 8/8] arm64: Wire up and expose the new compat vDSO Kevin Brodsky
2016-11-04 15:50   ` Catalin Marinas
2016-11-04 16:30     ` Kevin Brodsky
2016-11-04 16:47       ` Catalin Marinas
2016-11-04 17:53         ` Kevin Brodsky

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=70668250-d51b-a879-8ebf-66a07c178718@arm.com \
    --to=kevin.brodsky@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 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.