linux-kernel - Re: Better way to force a rebuild

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]

Message-ID: <20081210203740.GA16674@uranus.ravnborg.org>
Date:	Wed, 10 Dec 2008 21:37:40 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	rostedt@...dmis.org, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org, zippel@...ux-m68k.org, mingo@...e.hu
Subject: Re: Better way to force a rebuild

On Wed, Dec 10, 2008 at 12:10:48PM -0800, Andrew Morton wrote:
> On Wed, 10 Dec 2008 21:02:42 +0100
> Sam Ravnborg <sam@...nborg.org> wrote:
> 
> > On Wed, Dec 10, 2008 at 02:48:35PM -0500, Steven Rostedt wrote:
> > > 
> > > Hi,
> > > 
> > > In include/linux/kernel.h I currently have the following lines at the 
> > > bottom of the file:
> > > 
> > > /* Rebuild everything on CONFIG_FTRACE_MCOUNT_RECORD */
> > > #ifdef CONFIG_FTRACE_MCOUNT_RECORD
> > > # define REBUILD_DUE_TO_FTRACE_MCOUNT_RECORD
> > > #endif
> > > 
> > > 
> > > This is only there to force a rebuild of all files when 
> > > CONFIG_FTRACE_MCOUNT_RECORD is modified. Since the modification of that 
> > > config causes the build to act different, we need to rebuild all C 
> > > objects. I added the #ifdef in kernel.h as a hack to force the rebuild by 
> > > the config dependencies used in kbuild.
> > > 
> > > My question is, is there a better way to force a full rebuild on a 
> > > modification of a config?
> > 
> > Why is that hack required in the first place?
> > We rebuild if:
> > 1- target file is missing (not the case here)
> > 2- any prerequisite files are newer than target (not the case here)
> > 3- any CONFIG_* options used by any prerequisite has changed (not the case here)
> >   [It is due to your hack]
> > 4- gcc changed (not the case here)
> > 5- options are added/deleted to gcc (this should be the case for relevant files)
> > 
> 
> But damn me it's hard to work out where and how this is implemented :(

The magic is to be found in Kbuild.include:

# Usage: $(call if_changed_rule,foo)
# Will check if $(cmd_foo) or any of the prerequisites changed,
# and if so will execute $(rule_foo).
if_changed_rule = $(if $(strip $(any-prereq) $(arg-check) ),                 \
        @set -e;                                                             \
        $(rule_$(1)))


This parts takes care of:
$(any-prereq) takes care of 1 and 2 in the above list
$(arg-check) takes care of 4 and 5 in the above list.

And record_mcount is part of the following definition:
define rule_cc_o_c
        $(call echo-cmd,checksrc) $(cmd_checksrc)                         \
        $(call echo-cmd,cc_o_c) $(cmd_cc_o_c);                            \
        $(cmd_modversions)                                                \
        $(cmd_record_mcount)                                              \
        scripts/basic/fixdep $(depfile) $@ '$(call make-cmd,cc_o_c)' >    \
                                                      $(dot-target).tmp;  \
        rm -f $(depfile);                                                 \
        mv -f $(dot-target).tmp $(dot-target).cmd
endef

Here we use fixdep to create a set of prerequisites - one for each
CONFIG_ symbol that is found in the prerequisites. And fixdep reads the
list of prerequisites in the $(dep-file) that is created by gcc in the
cc_o_c command:

cmd_cc_o_c = $(CC) $(c_flags) -c -o $(@D)/.tmp_$(@F) $<


So after reading this you know almost as much about kbuild as I do.

I will fix the record_mcount stuff somehow.
But not tonight. Busy with work-work.

	Sam

--
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/