Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp533013imm; Thu, 31 May 2018 05:10:12 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIiHg36MHhMAqMrO8r9lRi5hN7nnmtNlLbgJnVWmBI6ue3Smf6o9zmlzm/Z3YSrPiIwA9fA X-Received: by 2002:a17:902:284b:: with SMTP id e69-v6mr6568000plb.240.1527768611981; Thu, 31 May 2018 05:10:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527768611; cv=none; d=google.com; s=arc-20160816; b=lObJxaMW+MgI5AwafysrWigicLSN2v+zCVyHvgbvt7gKiejeZAtR9ok6Nj7fo3nTpc sAUFw2QwO9lyMgnoMsVdS+8tyQKZRtVVUZ6WojHtoPcteg2HPFXlEax2lIExME9vw2qs ptbqF9/KvOmXWIDGF7Wdrqykk260/XbC62E5M6I9IklmzO5qgqikvadeASk6DQbRjKmZ F4StmZnnXn954/zv/Lb/YRAGNpZjT+iB/WWQMeowGZKrjh53VmEeMrenmH5hq2tdILmL 03HLjglbaPF+XwkUNzAXN2mWcPXJuGNXyoRDMX7IFYtRbts2PmdmadJZJqp5t8fsUZh3 aLJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:from:cc:content-transfer-encoding :mime-version:message-id:in-reply-to:subject:date:dkim-signature :arc-authentication-results; bh=IjlR5xckLi9d9dzpJDy6b509AIgmAiG3jDfHujmarCA=; b=iX4qeRsx5+P8yuH7sW49/SCHTLND28Ci3yfIciPAPODJK1TCFUJde5Vul1Z9Wd6nVz 8cDgBVOOFEM1HVRfphiXPjglGqOQUrJ1MkjpIdb4QKKMrA7jGDTFYSEGOpYcIEhLfp8S qsiS0/kNENun94zluhwD1gZs3IHb2ghKoaDcO0So87IgcPffz5WrQ2YkIrzq8scmPF7M ZaEkZuaZIRUWl/+SH5vHq4lQ/8hLJaXM/02asjHMbBukbhr/7LrQXm3WyaMFVGtyyHbu fHSHTdeNZSijitcT8XbL+aZ276+GNEP9bu9bDgCTWach6GVMRyghd4EHR8V3jRd7eywc A2Gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=FKjRnT5+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b59-v6si37137603plc.335.2018.05.31.05.09.57; Thu, 31 May 2018 05:10:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=FKjRnT5+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754880AbeEaMJZ (ORCPT + 99 others); Thu, 31 May 2018 08:09:25 -0400 Received: from mail-pl0-f66.google.com ([209.85.160.66]:39606 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754353AbeEaMJW (ORCPT ); Thu, 31 May 2018 08:09:22 -0400 Received: by mail-pl0-f66.google.com with SMTP id f1-v6so12692983plt.6 for ; Thu, 31 May 2018 05:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=date:subject:in-reply-to:message-id:mime-version :content-transfer-encoding:cc:from:to; bh=IjlR5xckLi9d9dzpJDy6b509AIgmAiG3jDfHujmarCA=; b=FKjRnT5+UaQWgMG4bfpRbhx17r4DHn7BLBzERglim3+fqo9TErZ8ymrkC/7ToV9BV+ SVCcdmBO9GtXZUWW5q0dVy2ZOFY3Z47e16DHZMXmm2ZQpg9iSsPAComuhq1aS3RXo6+k 3Y+9AerqF+Y/qSa29TyMSg19NWdkBVacVcE12/haJ03ndqTciKXL+LVmt+qgU2qo4Gxr AUORMLtNWnSX3Ookm9tGEE1ZtD7q8MOV5h6C8IvNeC3ejt82a0smsD4Qa3T3fqdgXfBA PdcOV0VPBP5RhbmFQ6uyba0bj8nPi8qQTIrXnC1cGRh6DdZKGaigyzaSaH52dJKPWgd9 9IaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:message-id:mime-version :content-transfer-encoding:cc:from:to; bh=IjlR5xckLi9d9dzpJDy6b509AIgmAiG3jDfHujmarCA=; b=tJzFJNcK10HP8XOZmGCVrJyuKAoowoQ6afeyIlI3153Cr7sU1DmE2EDlWDAAP26LkU sk5zYXJw+7ToW5GvsqbJWVMJ294B+a1F98e+JvwvQx58ExerS9mrliV5/oHYTj6Qi9Wm BJp6X/hw91/S0goqZC93bTNqCib/YOEVSXVka6TfRT0EmyGqfob0eKGotX9caZ7HCJ51 SY0cuW24Mvi5S9QOLBz/cN3wIpcZSI+JcPto8+zHGmltinhhHtDEHe5U4yIHTsHa9gG2 0JRsU7JHUrgVnc+D7iVr83CJkLfgFyzhQpORS/RPhf+9Rtg7Xid+QjJF2nXrP0P4r1C6 eTrg== X-Gm-Message-State: ALKqPwfFMytVflAA3t9aOwmwJ227LKySWz/Td2ovGigDZOn41dIomgAE VdahwGDFGG5V3l4ImwX0ccmxFA== X-Received: by 2002:a17:902:5481:: with SMTP id e1-v6mr6690195pli.137.1527768562260; Thu, 31 May 2018 05:09:22 -0700 (PDT) Received: from localhost ([1.214.161.170]) by smtp.gmail.com with ESMTPSA id d186-v6sm63462133pfa.79.2018.05.31.05.09.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 05:09:21 -0700 (PDT) Date: Thu, 31 May 2018 05:09:21 -0700 (PDT) X-Google-Original-Date: Thu, 31 May 2018 05:07:43 PDT (-0700) Subject: Re: [PATCH] riscv: pass machine size to sparse In-Reply-To: Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit CC: Christoph Hellwig , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, albert@sifive.com, michal.lkml@markovi.net From: Palmer Dabbelt To: yamada.masahiro@socionext.com, luc.vanoostenryck@gmail.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 28 May 2018 23:14:20 PDT (-0700), yamada.masahiro@socionext.com wrote: > 2018-05-29 15:11 GMT+09:00 Christoph Hellwig : >> On Mon, May 28, 2018 at 06:35:05PM +0200, Luc Van Oostenryck wrote: >>> By default, sparse assumes a 64bit machine when compiled on x86-64 >>> and 32bit when compiled on anything else. >>> >>> This can of course create all sort of problems when this doesn't >>> correspond to the target's machine size, like issuing false >>> warnings like: 'shift too big (32) for type unsigned long' or >>> is 64bit while sparse was compiled on a 32bit machine, or worse, >>> to not emit legitimate warnings. >>> >>> Fix this by passing the appropriate -m32/-m64 flag to sparse. >> >> Can we please move this to the common Kbuild code using the >> CONFIG_64BIT syombol? This really should not need boiler plate in >> every architecture. > > > I agree. > > Luc did so for -mbig/little-endian: > https://patchwork.kernel.org/patch/10433957/ > > We should do likewise for -m32/64. Sorry for being a bit slow here, but I like the idea of making the 32/64-bit issue generic as it seems like it'll be necessary for every port. Looking through the patch for big/little-endian I did notice: * RISC-V compilers set "__riscv_xlen" to the length of an X (integer) register in bits. * RISC-V compilers define "__riscv", and it doesn't appear we inform sparse about that. These two might not be that interesting, but we do already have some cases where we're checking for __riscv_xlen in Linux. I've yet to successfully use sparse, but adding at least CHECKFLAGS += -D__riscv seems reasonable, and possibly also some sort of ifeq ($(CONFIG_ARCH_RV64I),y) CHECKFLAGS += -D__riscv_xlen=64 else CHECKFLAGS += -D__riscv_xlen=32 fi might be necessary. We strive to follow the generic rules for ABI-related stuff like __LP64__ but I don't think there's any generic mapping for XLEN. Similarly there's "__riscv_flen" and "__riscv_float_abi_*", but those are less likely to be used by the kernel so they're probably not worth worrying about for now. There's also a bunch of other RISC-V macros, the only one of which we're currently using is "__riscv_muldiv" (and that's in a manner that's unlikely to trigger any sort of static analysis). Between a lack of Kconfig options and a glibc port we're essentially mandating IMA right now, so these probably don't matter. Thanks!