Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp988494pxb; Wed, 29 Sep 2021 14:15:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPu7NwZyUrf4EenTd3il9bw16h1mOKihTiIJapPsma+k9Y8lMHt5e6Ki6jyDyPLUgRoN1q X-Received: by 2002:a17:902:d345:b0:13e:27a5:58b5 with SMTP id l5-20020a170902d34500b0013e27a558b5mr549007plk.79.1632950144875; Wed, 29 Sep 2021 14:15:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632950144; cv=none; d=google.com; s=arc-20160816; b=HI9DsTe4hf25ko9DgGoDx2CU8FQrR2sxSI0Cr5OGPHMHZx3X8fhqnv6T2FjMOI2J5p XgxQHsnzduFDrMRwlDzlvzIKzqmkPvrQcQp+QTZYevoxRQFM0YLgetJZ9M5sXgd8rKcs 5wcx0CY/l47hinJ7RlFfoHbDYbsEiLpEu/vMhqFZfWWp0LzcMF/tYO+/OyUsv+LSg/WV sNnCps0l8oJmuHhNxR5ZPI0zAs/YlVUZx/kAuiISRU3ajwdMQ3lp1sd59+bjCN8eyc+8 oor5Iypw7zASNBSqQ/sGFE6gP3OQixxi6MYJjk1NoAZVEIT+E1gM5pJCnHKfiD5nwaWS ODkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=XRmGnlRvtNOeHtwOVOG8aQf7ZqqfjZr/UrlT6xJCshY=; b=nZSceGmB6uhB72HAMZEnCxhI5TbOsRixa8beoh4U3oRgOyx3CfBV8Ne9zFDVWjPcEK +d4sNbe1y91Vngyn46LKn2LlLsqdThvOkiukTrwTC+DBTBUICruhjTss+DyIFKNK6mIh WjXtWEgwVxl/ocBa7x+O6fBdUqKDuvCRhwRH1n0YqInTIEYYoRH5r4c4acAGufye0+7i VgJBPYTclImdzGpTH9sAyTkhuk42yJRNGPb+fN6vCKR9QwteGlx6JNg+BUuggYpjwBqM moa66WGvhPp67F2Isy62st4UJZyu+NGHH2OzluUr2hUscUvo3kaoxrd3dNApGN59M4tb vCZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=ouvL1PrG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id pj1si2441905pjb.110.2021.09.29.14.15.32; Wed, 29 Sep 2021 14:15:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=ouvL1PrG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346332AbhI2SyH (ORCPT + 99 others); Wed, 29 Sep 2021 14:54:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346078AbhI2SyG (ORCPT ); Wed, 29 Sep 2021 14:54:06 -0400 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AC2FC06161C for ; Wed, 29 Sep 2021 11:52:24 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id x27so14929992lfu.5 for ; Wed, 29 Sep 2021 11:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XRmGnlRvtNOeHtwOVOG8aQf7ZqqfjZr/UrlT6xJCshY=; b=ouvL1PrG01tFgjQ4aVDHTeUVJZ68s9IQbFf+IsLJdd6MCc939SLpWSW/e2x4ZZst1r NwyK2gaCY4ddAMU7AZiXEnHD2ogx/+y/MbhrpI000YAR8dF061+zGO/vjNQXiZQttEb/ k/if5rEj6+3jWrd5ulbBVfXZuR9NrySejc8XLCaJl5srRFbgA32LsNdTnQ6/qr2IYyL6 0lpCXPt7tF+no44k7uf2cUjgpt+u33utaaHNqif8qJbaDn0RPs2Rhxpn+Yp3jBeyBkf8 kptTY8ozbK86smYJt+q5JPplyNZvMOwLTUu7pHrzyTN69QhfAMoNODwC5B0Lmicv32Cj 9znw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XRmGnlRvtNOeHtwOVOG8aQf7ZqqfjZr/UrlT6xJCshY=; b=5u+JXjnQvmoV1n0qZ+gWro2Zoz7b0emFG4EkJnjoIb++5Q+9ek7TqPR1FpHfTkc3am yVRpGYkUoebsAFDd728J5jq4YYdOUcNfBKj7HNR1b/XtQO6t2l7as6O+bKzt8Il4NkZX DczNfBRmNPH59hDOIYzcWU/NHGznsEvp+illXExfnXlnfz9fTdaaYa3iLtS3C/RCd7uF vgpqvmDNh6vRrHRxA2f7BBSBrhdtwB9KGm34FAiogSpP6Kiw0aaSLxSCIB57GnTVTxLp sJK5Y0B55O+S7JH4x8vT9WHIyJxff1m3fD840PI6yG+G+XAPHD1X61RbPOK7cLbPxtv3 DrGg== X-Gm-Message-State: AOAM533fxLamJUftlFkmpCcIYk0n04bazAlaPr+oDyq/JffZxiSs1uQY awCZojAQ3MlwD2jjeA5r5mRdDZbbpWA1KCaGdtwt8w== X-Received: by 2002:a05:6512:110a:: with SMTP id l10mr1245290lfg.550.1632941542741; Wed, 29 Sep 2021 11:52:22 -0700 (PDT) MIME-Version: 1.0 References: <20210928154143.2106903-1-arnd@kernel.org> <20210928154143.2106903-7-arnd@kernel.org> In-Reply-To: <20210928154143.2106903-7-arnd@kernel.org> From: Nick Desaulniers Date: Wed, 29 Sep 2021 11:52:11 -0700 Message-ID: Subject: Re: [PATCH 06/14] ARM: disallow CONFIG_THUMB with ARMv4 To: Arnd Bergmann Cc: Russell King , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Arnd Bergmann , Ard Biesheuvel , Linus Walleij , Nathan Chancellor , llvm@lists.linux.dev, David Spickett Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 28, 2021 at 8:42 AM Arnd Bergmann wrote: > > From: Arnd Bergmann > > We can currently build a multi-cpu enabled kernel that allows both ARMv4 > and ARMv5 CPUs, and also supports THUMB mode in user space. > > However, returning to user space in this configuration with the usr_ret > macro requires the use of the 'bx' instruction, which is refused by > the assembler: > > arch/arm/kernel/entry-armv.S: Assembler messages: > arch/arm/kernel/entry-armv.S:937: Error: selected processor does not support `bx lr' in ARM mode > arch/arm/kernel/entry-armv.S:960: Error: selected processor does not support `bx lr' in ARM mode > arch/arm/kernel/entry-armv.S:1003: Error: selected processor does not support `bx lr' in ARM mode > :2:2: note: instruction requires: armv4t > bx lr > > While it would be possible to handle this correctly in principle, doing so > seems to not be worth it, if we can simply avoid the problem by enforcing does `mov pc, lr` work here, with a preprocessor guard on CPU_32v4? Or better yet... If `ret` is just an assembler macro (arch/arm/include/asm/assembler.h#L449), then perhaps always just using `ret` would be preferable here? In that case, it looks like `usr_ret` could be outright replaced with just expansions of `ret`? Just spitballing ideas; like you said, maybe not worth fixing. > that a kernel supporting both ARMv4 and a later CPU architecture cannot > run THUMB binaries. > > This turned up while build-testing with clang; for some reason, > gcc never triggered the problem. I suspect this is a Clang's integrated assembler vs GAS difference (compiler irrelevant); clang's assembler is more strict that `bx lr` requires armvt (CPU_32v4T). Though I can reproduce that exact message in local testing with GAS: $ cat foo.s bx lr $ arm-linux-gnueabi-as -march=armv4 -c foo.s foo.s: Assembler messages: foo.s:1: Error: selected processor does not support `bx lr' in ARM mode $ arm-linux-gnueabi-as -march=armv4t -c foo.s $ arm-linux-gnueabi-objdump -dr a.out ... 00000000 <.text>: 0: e12fff1e bx lr 0: R_ARM_V4BX *ABS* The `:2:2` makes me think of inline asm. > > Signed-off-by: Arnd Bergmann Reviewed-by: Nick Desaulniers > --- > arch/arm/mm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig > index 82aa990c4180..58afba346729 100644 > --- a/arch/arm/mm/Kconfig > +++ b/arch/arm/mm/Kconfig > @@ -675,7 +675,7 @@ config ARM_PV_FIXUP > > config ARM_THUMB > bool "Support Thumb user binaries" if !CPU_THUMBONLY && EXPERT > - depends on CPU_THUMB_CAPABLE > + depends on CPU_THUMB_CAPABLE && !CPU_32v4 > default y > help > Say Y if you want to include kernel support for running user space > -- > 2.29.2 > -- Thanks, ~Nick Desaulniers