[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] build: centralize / unify asm-offsets generation
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Tue, 27 Apr 2021 15:31:33 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l4qPPYs7ylAFq+D4F8H6y9XshZfXSK7Ok3uVpRHKs3E=; b=Ir7lBFGsh1841C4B6UCoYa0gHjy9XUfcyfacSJePm7s9CfdR4jW+90jhbrbW40TNl4cX5zjbPpUpaKgEcpNy1IKQvz46VWVQaOphRgvRSqvVk/ZWyRubOSAlwPmLRUGAGK3DN5MuVRV4/HSYZcGPrNqv0iNGMXAn1K3DfjVfimQAG0SjrUy4tJVsb81z/lpL6q4SHAfx4y7IYsPP1cjZ+nob8kPbFkXtupyPWUOu44CCru9ihvb0Ot9wH09Rak4cidqV4CwURQEJpCpzwzG1tcPYmggKQ4Kwe7o4ApkI0/GK5SFSvBPNU9iOUErMd8RojCQn8bmFy6eBAjhYN08sAw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZGjv/N2ZFZY92QInw01b9flEiEuEJm09AD/GB3102Hse3tUeIPI624RCo7rkLUZ9hTvVtHP25/rhsGOIyRsVBleMYJtmFOEY58JRVQy+4MS8oZzs3xy6yUCNMPfeOOAkIsy1A+jr2gYbH11Uzt9Ws0dcxP7SLG1eR1rxnFD57sQqlDuqpO1iq+jeVAnpFmKlkB+MAfS3mO43CXZhkMGX6A1cbfVyis0G+HGBIjK+t/XxCT8h9PoMXPkHzsIpn5rJSu8gEghRBUfXRYuEjfSR9Z/OYiNOKcbWMgJ7Vo73M0iw72B8P9+5m9iBrujV4RhlokQnGzhbh3+hQ+exUb4EOw==
- Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Tue, 27 Apr 2021 13:31:53 +0000
- Ironport-hdrordr: A9a23:JvxXf6sU3xfTJ7w2IU17dyh97skCxoYji2hD6mlwRA09T+WxrO rrtOgH1BPylTYaUGwhn9fFA6WbXXbA7/dOjrU5FYyJGC3ronGhIo0n14vtxDX8Bzbzn9Qw6Y 5JSII7MtH5CDFB4PrSyBWkEtom3dmM+L2pg+Cb9Ht2UQR2cchbjjtRICzzKDwQeCBtA50lGJ 2AoudGvSOnY3QLbsK9b0N1JdTrjdvNiZ7gfFo6HBYh8gaDlneF77T9Hhie0H4lIk5y6J0l9n XIlBG827W7v5iAu2Th/kLwz7ATotvuzdNfGNeB4/J6FhzAghulDb4ROYGqkysypIiUmTMXuf nK5ywtJsFir07WF1vF3SfF/ynF/HIQ52T5yVme6EGT0fDRYD4hEcJOicZ4X3LimjMdlepx2q 5KwG6V3qA/ZXir/FWflqr1fipnmUaurX0pnfR7tQ0mbaIkZKJMtotaxUtJEf47bVPHwbo6G+ pjBty03ocxTXqmaRnizw1S6e3pdHEyEhCae1MFq8yY3hNH9UoJsXcw9YgxmGwN+4k6TIQBz+ PYMr5wnLULdcMOa7lhbd1xDfefOyjoe1bhIWiSKVPoGOUuPG/MkYf+5PEQ6PuxcJIF4ZMukP 36IRxlnF93X3irJdyF3ZVN/ByIan66Ry7RxsZX4IU8kqHgRZLwWBfzCGwGoo+FmbEyE8fbU/ G8NNZ9GPn4N1bjHo5PwknXR4RSE38DS8cY0+xLGm6mk4buEMnHp+bbePHcKP7GCjA/QF7yBX MFQXzdP8NFwke3WmLpoRTYVn/3E3aPv65YIez/xaw+2YINPopDvkw+klKi/PyGLjVEr+gXcS JFUfbau5L+gVPz0XfD7m1vNBYYJF1S+q/cX3RDohJPF0v1dL0EquiOYGw65grCGjZPC+ftVC JPrVV+/qy6a7aKwzo5Nt6hOmWGy1weuWyNVJVZvqGY/8/qdtcZA/8dKeJMPDSOMyYwtRdhqW 9FZgNBbFTYDCnShaKsi4FRIvreedl6iAKCOtVVtnrbiEWZqagUNzgmdg/rdfTSrRclRjJSiF E02bQYmqC8lTGmLnZ6vP41K2RWaGOcAKtPCSOMYIk8oMGtRChACUOxwRCKgRA6fWTns2EfnH boIyGvdfbXOVZFoXxD3qH28FR7S3WFcytLGwNHmLw4MV6Dlmd40OeNaKb26WeXZ1cY6sw2MT 3OY1IpU0hT7uHy8CTQtCeJFH0gyJlrA/fUC647darPnlm3LpeTqK0AF/hI3ZpsOdz0qNUXWe aHdwL9FkK/N8oZnyiu4lo1Mih9r3cp1c7y0Br+9W6iwToRB+HRLFkOfcBsH/isq0zfA9CG35 VygYhr4a+eMmDtZsWHzq+SRThZMR/XqXO3SeZtiZ08h9NHiJJDW73gFR3P3zV7+T97CuHevk YXWr5677DMIZUHRb1bRwtpun4S0O2SJ04quDHsCuAwfVsRn2bWVun5lobgmP4KOAm9vwP+Nl mUzj1F89rEVyWF06QGC6hYGxUgVGEMrFBj9viFbYveFUGDcPxC5kOzNhaGAfVgYZnAPbUbtR Bh5d6U28eRairjwQjV+R92OLhH/WriYcS8Bmu3aKN12u3/HVSHma2x5sGvyB/xVDugckwdwb R/SnZ4VLULthASyKst0iazTaTrokUq13tmiAsX6WLF68yB+2fUHUZPLAvDpI5ZNAMja0S1sQ ==
- Ironport-sdr: +L1ODzA2H4Z9vnOQlSjSRcHxwv2hcRKVXIhUH/aXZZCPwIGLaXgiTsFIWLoMKaAu6QEB6leObt FnTul0ojgs6SJb7YKEE0vOgiKWQNCoiKTJjrwJxlBhMYly82HYZNsVUpIfJXqYfdqOZSJDERpG 7N6SCEhHTsQsvQoPrJAvnMpfrq3fRXpFSjpN0jB5dMrip2rnxrafvNIjh1xJUaZGRyWX3dcM9y 2aJbRpZywgu7sKZ69EkoNE4sgbcYZPt167ogw9e4B3WleRccLnrRPgLprEEr8lPvjfVuuo7v5w GOQ=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Tue, Apr 27, 2021 at 02:30:35PM +0200, Jan Beulich wrote:
> On 27.04.2021 11:05, Roger Pau Monné wrote:
> > On Wed, Apr 21, 2021 at 04:09:03PM +0200, Jan Beulich wrote:
> >> On 20.04.2021 18:20, Roger Pau Monné wrote:
> >>> On Tue, Apr 20, 2021 at 05:47:49PM +0200, Jan Beulich wrote:
> >>>> On 20.04.2021 17:29, Roger Pau Monné wrote:
> >>>>> On Thu, Apr 01, 2021 at 10:33:47AM +0200, Jan Beulich wrote:
> >>>>>> @@ -399,7 +399,11 @@ include/xen/compile.h: include/xen/compi
> >>>>>> @sed -rf tools/process-banner.sed < .banner >> $@.new
> >>>>>> @mv -f $@.new $@
> >>>>>>
> >>>>>> -include/asm-$(TARGET_ARCH)/asm-offsets.h:
> >>>>>> arch/$(TARGET_ARCH)/asm-offsets.s
> >>>>>> +asm-offsets.s: arch/$(TARGET_ARCH)/$(TARGET_SUBARCH)/asm-offsets.c
> >>>>>> + $(CC) $(filter-out -Wa$(comma)% -flto,$(c_flags)) -S -g0 -o
> >>>>>> $@.new -MQ $@ $<
> >>>>>> + $(call move-if-changed,$@.new,$@)
> >>>>>
> >>>>> Won't it be more natural to keep the .s file in arch/$(TARGET_ARCH)?
> >>>>
> >>>> Yes and no: Yes as far as the actual file location is concerned.
> >>>> No when considering where it gets generated: I generally consider
> >>>> it risky to generate files outside of the directory where make
> >>>> currently runs. There may be good reasons for certain exceptions,
> >>>> but personally I don't see this case as good enough a reason.
> >>>>
> >>>> Somewhat related - if doing as you suggest, which Makefile's
> >>>> clean: rule should clean up that file in your opinion?
> >>>
> >>> The clean rule should be in the makefile where it's generated IMO,
> >>> same as asm-offsets.h clean rule currently in xen/Makefile.
> >>>
> >>>> Nevertheless, if there's general agreement that keeping the file
> >>>> there is better, I'd make the change and simply ignore my unhappy
> >>>> feelings about it.
> >>>
> >>> I don't have a strong opinion, it just feels weird to have this IMO
> >>> stray asm-offsets.s outside of it's arch directory, taking into
> >>> account that we have asm-offsets.h generated from xen/Makefile into an
> >>> arch specific directory already as a precedent in that makefile.
> >>
> >> Well, asm-offsets.h generation doesn't involve the compiler, hence
> >> no .*.d files get generated and want including later. For
> >> asm-offsets.s to have dependencies properly honored, if we
> >> generated it in xen/arch/<arch>, .asm-offsets.d would also end up
> >> there, and hence including of it would need separately taking care
> >> of.
> >
> > I'm not sure I understand what do you mean with inclusion need taking
> > care of separately. Isn't it expected for .d file to reside in the
> > same directory as the output,
>
> Yes, ...
>
> > and hence picked up automatically?
>
> ... and hence they _wouldn't_ be picked up automatically while
> building in xen/ if the .s file got created in xen/arch/<arch>/.
Hm, so that would prevent re-building the target when the dependencies
changed as the .d file being in the arch directory would attempt the
rebuild from there instead of the top level xen/?
I guess the alternative would be to force a rebuild of the target
every time, in order to not depend on the .d logic?
Thanks, Roger.
|