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

Re: [XEN PATCH v4 15/18] xen/build: use if_changed to build guest_%.o

On 16.04.2020 14:57, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 03:02:21PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:30, Anthony PERARD wrote:
>>> Use if_changed for building all guest_%.o objects, and make use of
>>> command that already exist.
>>> This patch make a change to the way guest_%.o files are built, and now
>>> run the same commands that enforce unique symbols. But with patch
>>> "xen,symbols: rework file symbols selection", ./symbols should still
>>> select the file symbols directive intended to be used for guest_%.o
>>> objects.
>> I'm having trouble making the connection between the change to the
>> symbols tool and the adjustments made here:
> The change to symbol tool is to allow this change.

I've been understanding the fact, but I still don't understand why
the adjustment to that tool is necessary for the change here to be

>>> --- a/xen/arch/x86/mm/Makefile
>>> +++ b/xen/arch/x86/mm/Makefile
>>> @@ -11,11 +11,13 @@ obj-y += p2m.o p2m-pt.o
>>>  obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o
>>>  obj-y += paging.o
>>> -guest_walk_%.o: guest_walk.c Makefile
>>> -   $(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
>> The original rules didn't do anything special to arrange for the
>> resulting kallsyms names; these arrangements instead live at the
>> top of the respective source files, in the form of asm()-s.
> They still are. I try to consolidate the number of location which have
> command that build a target. Those guest_%.o object aren't special
> enough to deserve to be built in a different way than every other
> object. They do need a different make rule, but they can use the same
> command.

Again, I understand what the goal is, but not what it is that
changes (and why) in the produced file symbols, making the utility
adjustment necessary. I guess it's obvious to you, but it looks as
if I was dense, sorry.




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