All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Michal Marek <mmarek@suse.com>, Will Deacon <will.deacon@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kbuild@vger.kernel.org
Subject: Re: [PATCH RESEND] arm64: fix vdso-offsets.h dependency
Date: Thu, 7 Jul 2016 12:23:25 +0100	[thread overview]
Message-ID: <20160707112325.GB27180@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <20160707102601.GA27180@e104818-lin.cambridge.arm.com>

On Thu, Jul 07, 2016 at 11:26:01AM +0100, Catalin Marinas wrote:
> On Wed, Jul 06, 2016 at 06:57:39PM +0100, Catalin Marinas wrote:
> > On Thu, May 12, 2016 at 05:39:15PM +0100, Kevin Brodsky wrote:
> > > +# We need to generate vdso-offsets.h before compiling certain files in kernel/.
> > > +# In order to do that, we should use the archprepare target, but we can't since
> > > +# asm-offsets.h is included in some files used to generate vdso-offsets.h, and
> > > +# asm-offsets.h is built in prepare0, for which archprepare is a dependency.
> > > +# Therefore we need to generate the header after prepare0 has been made, hence
> > > +# this hack.
> > > +prepare: vdso_prepare
> > > +vdso_prepare: prepare0
> > > +	$(Q)$(MAKE) $(build)=arch/arm64/kernel/vdso include/generated/vdso-offsets.h
> > 
> > This indeed looks dodgy. I'm not sure about the makefile rules but would
> > the above override the "prepare" target in the top Makefile?
> > 
> > I think a dependency problem we have is that arch/arm64/kernel/signal.o
> > depends on include/generated/vdso-offsets.h. However, we don't have any
> > target for the latter, only for
> > $(objtree)arch/arm64/kernel/vdso/vdso-offsets.h which no-one is
> > including. Because of this, we have a fake dependency in
> > arch/arm64/kernel/Makefile.
> > 
> > -----------8<-------------------------
> > diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> > index 7700c0c23962..9bdacbf59091 100644
> > --- a/arch/arm64/kernel/Makefile
> > +++ b/arch/arm64/kernel/Makefile
> > @@ -55,5 +55,4 @@ head-y					:= head.o
> >  extra-y					+= $(head-y) vmlinux.lds
> >  
> >  # vDSO - this must be built first to generate the symbol offsets
> > -$(call objectify,$(arm64-obj-y)): $(obj)/vdso/vdso-offsets.h
> > -$(obj)/vdso/vdso-offsets.h: $(obj)/vdso
> > +$(objtree)/include/generated/vdso-offsets.h: $(obj)/vdso
> 
> This didn't work either. Basically, when building
> arch/arm64/kernel/signal.o for example, it doesn't figure out that
> vdso-offsets.h has additional dependencies like the vdso.so.dbg so that
> it builds the vdso object first. I'll look for a little longer, maybe I
> find a better workaround.

If I also add the patch below, it works fine but I'm not sure we can
guarantee that kbuild first dives into subdirectories with a parallel
build:

--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -49,11 +49,7 @@ arm64-obj-$(CONFIG_HIBERNATION)		+= hibernate.o hibernate-asm.o
 arm64-obj-$(CONFIG_KEXEC)		+= machine_kexec.o relocate_kernel.o	\
 					   cpu-reset.o
 
-obj-y					+= $(arm64-obj-y) vdso/
+obj-y					+= vdso/ $(arm64-obj-y)
 obj-m					+= $(arm64-obj-m)
 head-y					:= head.o
 extra-y					+= $(head-y) vmlinux.lds

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RESEND] arm64: fix vdso-offsets.h dependency
Date: Thu, 7 Jul 2016 12:23:25 +0100	[thread overview]
Message-ID: <20160707112325.GB27180@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <20160707102601.GA27180@e104818-lin.cambridge.arm.com>

On Thu, Jul 07, 2016 at 11:26:01AM +0100, Catalin Marinas wrote:
> On Wed, Jul 06, 2016 at 06:57:39PM +0100, Catalin Marinas wrote:
> > On Thu, May 12, 2016 at 05:39:15PM +0100, Kevin Brodsky wrote:
> > > +# We need to generate vdso-offsets.h before compiling certain files in kernel/.
> > > +# In order to do that, we should use the archprepare target, but we can't since
> > > +# asm-offsets.h is included in some files used to generate vdso-offsets.h, and
> > > +# asm-offsets.h is built in prepare0, for which archprepare is a dependency.
> > > +# Therefore we need to generate the header after prepare0 has been made, hence
> > > +# this hack.
> > > +prepare: vdso_prepare
> > > +vdso_prepare: prepare0
> > > +	$(Q)$(MAKE) $(build)=arch/arm64/kernel/vdso include/generated/vdso-offsets.h
> > 
> > This indeed looks dodgy. I'm not sure about the makefile rules but would
> > the above override the "prepare" target in the top Makefile?
> > 
> > I think a dependency problem we have is that arch/arm64/kernel/signal.o
> > depends on include/generated/vdso-offsets.h. However, we don't have any
> > target for the latter, only for
> > $(objtree)arch/arm64/kernel/vdso/vdso-offsets.h which no-one is
> > including. Because of this, we have a fake dependency in
> > arch/arm64/kernel/Makefile.
> > 
> > -----------8<-------------------------
> > diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> > index 7700c0c23962..9bdacbf59091 100644
> > --- a/arch/arm64/kernel/Makefile
> > +++ b/arch/arm64/kernel/Makefile
> > @@ -55,5 +55,4 @@ head-y					:= head.o
> >  extra-y					+= $(head-y) vmlinux.lds
> >  
> >  # vDSO - this must be built first to generate the symbol offsets
> > -$(call objectify,$(arm64-obj-y)): $(obj)/vdso/vdso-offsets.h
> > -$(obj)/vdso/vdso-offsets.h: $(obj)/vdso
> > +$(objtree)/include/generated/vdso-offsets.h: $(obj)/vdso
> 
> This didn't work either. Basically, when building
> arch/arm64/kernel/signal.o for example, it doesn't figure out that
> vdso-offsets.h has additional dependencies like the vdso.so.dbg so that
> it builds the vdso object first. I'll look for a little longer, maybe I
> find a better workaround.

If I also add the patch below, it works fine but I'm not sure we can
guarantee that kbuild first dives into subdirectories with a parallel
build:

--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -49,11 +49,7 @@ arm64-obj-$(CONFIG_HIBERNATION)		+= hibernate.o hibernate-asm.o
 arm64-obj-$(CONFIG_KEXEC)		+= machine_kexec.o relocate_kernel.o	\
 					   cpu-reset.o
 
-obj-y					+= $(arm64-obj-y) vdso/
+obj-y					+= vdso/ $(arm64-obj-y)
 obj-m					+= $(arm64-obj-m)
 head-y					:= head.o
 extra-y					+= $(head-y) vmlinux.lds

-- 
Catalin

  reply	other threads:[~2016-07-07 11:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-12 16:39 [PATCH RESEND] arm64: fix vdso-offsets.h dependency Kevin Brodsky
2016-05-12 16:39 ` Kevin Brodsky
2016-07-06 17:57 ` Catalin Marinas
2016-07-06 17:57   ` Catalin Marinas
2016-07-07 10:26   ` Catalin Marinas
2016-07-07 10:26     ` Catalin Marinas
2016-07-07 11:23     ` Catalin Marinas [this message]
2016-07-07 11:23       ` Catalin Marinas
2016-07-07 18:08       ` Catalin Marinas
2016-07-07 18:08         ` Catalin Marinas
2016-07-08 11:27 ` Catalin Marinas
2016-07-08 11:27   ` Catalin Marinas
2016-07-11 15:29   ` Kevin Brodsky
2016-07-11 15:29     ` Kevin Brodsky
2016-07-11 16:19     ` Catalin Marinas
2016-07-11 16:19       ` Catalin Marinas
2016-07-12  9:17       ` Kevin Brodsky
2016-07-12  9:17         ` Kevin Brodsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160707112325.GB27180@e104818-lin.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=mmarek@suse.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.