[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] coverage: filter out lib{fdt,elf}-temp.o


  • To: Anthony PERARD <anthony.perard@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • From: Michal Orzel <michal.orzel@xxxxxxx>
  • Date: Mon, 22 Jan 2024 12:19:22 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EGQvmtIofyN7O9/Qk/4JVihYSkBbWHQUWSyRZo2mQ+8=; b=Dxrfg7fG8/4aPyDDpl2LNQtBgZqojBDVme5OvXDarAATafdHQA2yizAAXrlTZRjMPDBPusJDZwOZZXfZXjbYuPttnnMOANqQ7oD90XphDkYPpftQ6uo3pCB9mzEnGIpF8bxWPe+IYUVB4z4f7x9K1yJGPGaQiTgt0hn8VcwKuzJmYWe5B77CaiTyjAnH/4S4AGlS21lirNdxJTMqa0CEEbGxoJUB5F/8ugxnjOCKZ2i7NWcT1xoDA7TkdhY5fA60LwiFKuA61UPXirxiUVCnaFbnAIP0QO4UOXhB2Nle1nFkSA1vfkLKUrgKSOeTzcm1Tu+BqznM1TwnjQSJrPrZJQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IPHcWQ9kJmS0gyV1OztmXpG0+CqUP6K5WljNo8ltCX/quIi4v/LpB5yMlw6Ane9++bBMV7zeXWN0fbHtBXeGTbyhn5pm5QflPOVOVfXU2VHAAVXjkjyKqxHJIW7PXKTMQSG6zJef/+ow8mfUxP942t3+24bxlT/rh3aAG6I8V4e51VpLbRGay/jqyMN8pGjGbCmzYPaOrM77zGNc4efl7nrWlcHNPzDK52U0wu7l031NNI3B/fJjJ9CL+sHHZUCsmKPwfD8PKMFUhfPqIyaQnwBedCTOToN13ivjhNr/Gb/OA3kgtzTYuLhhDW/KClPC1mqUl9KTeTQj7lCniA99Rw==
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Javi Merino <javi.merino@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 22 Jan 2024 11:19:40 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 22/01/2024 12:05, Anthony PERARD wrote:
> 
> 
> On Mon, Jan 22, 2024 at 10:54:13AM +0000, Anthony PERARD wrote:
>> On Mon, Jan 22, 2024 at 11:04:41AM +0100, Jan Beulich wrote:
>>> On 19.01.2024 16:25, Anthony PERARD wrote:
>>>> On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
>>>>> Is my understanding correct that by switching from extra-y to targets we 
>>>>> are preventing these objects to
>>>>> appear in non-init-objects (and thus having COV_FLAGS appended) while 
>>>>> retaining the proper if_changed behavior?
>>>>>
>>>>> According to docs/misc/xen-makefiles/makefiles.rst:
>>>>> Any target that utilises if_changed must be listed in $(targets),
>>>>> otherwise the command line check will fail, and the target will
>>>>> always be built.
>>>>
>>>> Indeed, and $(extra-y) is added to $(targets) via
>>>> $(targets-for-builtin).
>>>>
>>>> While switching from $(extra-y) to $(targets) prevents the objects from
>>>> been added to $(non-init-objets), it doesn't matter because "libelf.o"
>>>> is in that variable, so $(COV_FLAGS) is added to $(_c_flags) and its
>>>> value is used in all the prerequisites of "libelf.o" which includes
>>>> "libelf-temp.o" and for example "libelf-dominfo.o". So the only thing
>>>> preventing $(COV_FLAGS) from been added when building "libelf-tools.o"
>>>> for example is that we set `COV_FLAGS:=` for "libelf.o".
>>>
>>> Yet doesn't that (again) mean things should actually work as-is, [...]
>>
>> No, because I've explain how it should work, in the hypothetical world
>> where we have `targets += libelf-temp.o $(libelf-objs)`.
> 
> The problem is that there's currently two "paths" to build libelf-temp.o
> (and even three I think for libelf-tools.o libelf-loader.o
> libelf-dominfo.o):
> 
> Simplified makefile:
> 
>     obj-y := libelf.o
>     extra-y := libelf-temp.o
>     COV_FLAGS := -fcoverage
> 
>     __build: $(extra-y) built_in.o
>     built_in.o: $(obj-y)
>     libelf.o: COV_FLAGS :=
>     libelf.o: libelf-temp.o
> 
> So, make can build "libelf-temp.o" as prerequisite of "__build" the
> default target, or as prerequisite of "libelf.o".
> In the first case, COV_FLAGS would have all the flags, and in the second
> case, COV_FLAGS would be reset, but that second case is too late as make
> is more likely to have already built libelf-temp.o with all the flags.

Thanks for detailed explanation. I will follow your rationale in v2.

~Michal



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.