linux-kernel - Re: [PATCH] Fix compiler message generation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 Jul 2014 14:40:16 +0200
From:	Michal Marek <mmarek@...e.cz>
To:	David Howells <dhowells@...hat.com>
Cc:	torvalds@...ux-foundation.org, sam@...nborg.org,
	linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
	Boaz Harrosh <boaz@...xistor.com>
Subject: Re: [PATCH] Fix compiler message generation

On Wed, Jul 02, 2014 at 11:56:46AM +0100, David Howells wrote:
> The following commit:
> 
> 	commit 9da0763bdd82572be243fcf5161734f11568960f
> 	Author: Michal Marek <mmarek@...e.cz>
> 	Date:   Fri Apr 25 23:25:18 2014 +0200
> 	Subject: kbuild: Use relative path when building in a subdir of the source tree
> 
> makes compiler messages relative to the *build* tree if the build tree is a
> subdirectory at the root of the source tree.
> 
> This is the wrong thing to do since the make command is issued in the *source*
> tree and so any editor or IDE that issues the make command will likely expect
> paths in warnings and errors to be relative either to the current directory at
> the time the make was issued or to the directory in which make was run.
> 
> Certainly, this is something I'm seeing with emacs.  I do:
> 
> 	LANG=C nice -19 make O=build -C /data/fs/linux-2.6-fscache -j4
> 
> And then I get error messages that look like:
> 
> 	../fs/namei.c: In function 'SYSC_linkat':
> 	../fs/namei.c:4836:57: error: expected declaration specifiers before 'x'
> 		int, newdfd, const char __user *, newname, int, flags)x
> 
> which emacs can't find the source for because it doesn't relate to anything
> emacs knows about.
> 
> As a temporary measure, fix this by substituting the full path of the source
> as make knows it.

Boaz Harrosh hit the same problem with kdevelop and posted a patch that
adds a variable to turn off relative paths:
https://lkml.org/lkml/2014/6/19/295. This has the downside that one has
to remember to set the variable.

However, VPATH builds are not that uncommon, so I guess the editors and
IDEs can actually handle them if make prints the "Entering directory
`blah/blah'" messages. We disable this in kbuild to not pollute the log,
but how about the following patch? I tried it with vim and it worked:


>From 5b59dcacf358f143b9fb39d2f788142ab9ba3e00 Mon Sep 17 00:00:00 2001
From: Michal Marek <mmarek@...e.cz>
Date: Wed, 2 Jul 2014 14:28:26 +0200
Subject: [PATCH] kbuild: Print the name of the build directory

With commit 9da0763b (kbuild: Use relative path when building in a
subdir of the source tree), the compiler messages include relative
paths. These are however relative to the build directory, not the
directory where make was started. Print the "Entering directory ..."
message once, so that IDEs/editors can find the source files.

Signed-off-by: Michal Marek <mmarek@...e.cz>
---
 Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Makefile b/Makefile
index 97b2861..40544a0 100644
--- a/Makefile
+++ b/Makefile
@@ -126,7 +126,10 @@ PHONY += $(MAKECMDGOALS) sub-make
 $(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all: sub-make
 	@:
 
+# Fake the "Entering directory" message once, so that IDEs/editors are
+# able to understand relative filenames.
 sub-make: FORCE
+	@echo "make[1]: Entering directory \`$(KBUILD_OUTPUT)'"
 	$(if $(KBUILD_VERBOSE:1=),@)$(MAKE) -C $(KBUILD_OUTPUT) \
 	KBUILD_SRC=$(CURDIR) \
 	KBUILD_EXTMOD="$(KBUILD_EXTMOD)" -f $(CURDIR)/Makefile \
-- 
1.8.4.5



> I suspect the correct fix from make's point of view is to issue the build
> command in the build tree and use VPATH to refer to the source, but that would
> likely involve making a lot of Makefiles and would involve a step equivalent
> to autoconf - which is probably not what we want.

The build does run in the build tree with VPATH = $(srctree). The first
make just passes over to a make -C $(objtree).

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/