From patchwork Thu Mar 22 21:05:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rasmus Villemoes X-Patchwork-Id: 10302323 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A75D260216 for ; Thu, 22 Mar 2018 21:05:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 97CC4289E7 for ; Thu, 22 Mar 2018 21:05:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8BA99289E9; Thu, 22 Mar 2018 21:05:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1985F289E8 for ; Thu, 22 Mar 2018 21:05:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751745AbeCVVFk (ORCPT ); Thu, 22 Mar 2018 17:05:40 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:38993 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751599AbeCVVFa (ORCPT ); Thu, 22 Mar 2018 17:05:30 -0400 Received: by mail-wm0-f66.google.com with SMTP id f125so52960wme.4 for ; Thu, 22 Mar 2018 14:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=3GOz+UaG1BFnOhaDN6iRw7dEiI48nYoIVPAPJCVsocI=; b=idzZOaxEEHQmNdCaNF7rblre1bbbq6j9IUIUHieIkmgdb25R6mvlOPQn4IubAj9vtA U6tUeHBt1v1/spnsMOb5hUlK+fNDDO/omKRJHTV1YBx0L0pSZ08+umcWovKTeumhCPfu ScAEvZGFTSkJE5Hel6qktyoHKf1JfOuNl2AMQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=3GOz+UaG1BFnOhaDN6iRw7dEiI48nYoIVPAPJCVsocI=; b=qlhZqhLCLLVmm2dnWoky+oZ4kx0ZAIsDl5s1UeZy01dzV4LYN3bVgrZI6/NIvQizBt I6wmr54tRdKjT5p6f0eY/J2yxAe2G+djlNoK8HZqCUUjuP/OoTBwFYZleplJ1w3BhT+o p00W5Hb17xx8GiWek+57axJpofABI6+f2LP7zU7c+w4sGoebr7H2hTy9j7q4mHZmRxNS xQWupUdGS46Wt6mwyXUuUI1fQ/2KX+J5bUtS+JNiMN2Uuy2411X+p3g6/0Py6U/W11sf 7AK3vagr2PVTNrMtLpZDsbsW5C8YNA6AYV2tnYNwdG7hVBH0P5RTG9//ZqlmNLj9Rom5 GWSQ== X-Gm-Message-State: AElRT7EJRcH32fr8MVKL2YzaGjXS4KWiS9ztsynFFN+iLSRdw4Cl2uBq buTokqgHcYzG+kgI9MiQYT7Q4A== X-Google-Smtp-Source: AG47ELupWl466AHD+hMa82ihjnJbWSHo4TP2xrj8VxUNQoIO3Y6ZbXpDCpy+IpjZ4Jlx1NCj+mS20g== X-Received: by 10.80.205.81 with SMTP id d17mr26843799edj.269.1521752729097; Thu, 22 Mar 2018 14:05:29 -0700 (PDT) Received: from prevas-ravi.waoo.dk (dhcp-5-186-126-104.cgn.ip.fibianet.dk. [5.186.126.104]) by smtp.gmail.com with ESMTPSA id w1sm5315169edk.82.2018.03.22.14.05.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 22 Mar 2018 14:05:28 -0700 (PDT) From: Rasmus Villemoes To: Masahiro Yamada , Michal Marek Cc: Rusty Russell , Sam Ravnborg , Rasmus Villemoes , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC resend 2/2] modpost: sumversions: try to fix "same dir" logic Date: Thu, 22 Mar 2018 22:05:24 +0100 Message-Id: <20180322210525.25361-2-linux@rasmusvillemoes.dk> X-Mailer: git-send-email 2.15.1 In-Reply-To: <20180322210525.25361-1-linux@rasmusvillemoes.dk> References: <20180322150005.15061-2-linux@rasmusvillemoes.dk> <20180322210525.25361-1-linux@rasmusvillemoes.dk> Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The current logic for deciding whether to parse a file listed in the .o.cmd file matches neither "is in same dir" (implied by the comment here), nor the "/* Sum all files in the same dir or subdirs. */" a little higher up. For example, for an object file in the top-level crypto/ directory, we end up also parsing anything it includes from include/crypto/ (though not subdirectories of that) and arch/x86/include/asm/crypto/. On the other hand, we never parse anything included from subdirectories of the object file's directory, contrary to at least one of the comments. This tries to fix things so that we actually implement "parse stuff found in $(dirname $objfile) and below" by simply checking whether line begins with dir. It doesn't quite work, though, because there are some #include "../blabla" directives, e.g. in drivers/scsi/libsas/ we have #include "../scsi_sas_internal.h", and gcc doesn't normalize the path before printing it, so we have drivers/scsi/libsas/../scsi_sas_internal.h in the .o.cmd file. But perhaps that's actually a good thing - then the logic would be something like "if gcc found the included file using . as starting point, we include it - otherwise it was found via some -I path, so do not include it". In any case, this is mostly just something I stumbled on because I'm about to change the .o.cmd layout slightly, so I'd like to know what the rules are really supposed to be. Signed-off-by: Rasmus Villemoes --- Resending because I didn't reach any current kbuild maintainers nor the kbuild mailing list. scripts/mod/sumversion.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/mod/sumversion.c b/scripts/mod/sumversion.c index 0f6dcb4011a8..e4f83fb9da2f 100644 --- a/scripts/mod/sumversion.c +++ b/scripts/mod/sumversion.c @@ -368,7 +368,7 @@ static int parse_source_files(const char *objfile, struct md4_ctx *md) } /* Check if this file is in same dir as objfile */ - if ((strstr(line, dir)+strlen(dir)-1) == strrchr(line, '/')) { + if (strncmp(line, dir, dirlen) == 0) { if (!parse_file(line, md)) { warn("could not open %s: %s\n", line, strerror(errno));