Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.04.2020 14:44, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:30, Anthony PERARD wrote:
>>> We want to use the same rune to build mm/*/guest_*.o as the one use to
>>> build every other *.o object. The consequence it that file symbols that
>>> the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
>>>
>>> (1) Currently we have those two file symbols:
>>>     guest_walk.c
>>>     guest_walk_2.o
>>> (2) with CONFIG_ENFORCE_UNIQUE_SYMBOLS used on guest_walk.c, we will have:
>>>     arch/x86/mm/guest_walk.c
>>>     guest_walk_2.o
>>>
>>> The order in which those symbols are present may be different.
>>>
>>> Currently, in case (1) ./symbols chooses the *.o symbol (object file
>>> name). But in case (2), may choose the *.c symbol (source file name with
>>> path component) if it is first
>>>
>>> We want to have ./symbols choose the object file name symbol in both
>>> cases.
>>
>> I guess the reason for wanting this is somehow connected to the
>> statement at the beginning of the description, but I can't seem
>> to be able to make the connection.
> 
> I'm not sure I can explain it better.
> 
> The "object file name" file symbol is used to distinguish between symbols
> from all mm/*/guest_* objects. The other file symbol present in those
> object is a "source file name without any path component symbol".
> 
> But building those objects with the same rune as any other objects, and
> having CONFIG_ENFORCE_UNIQUE_SYMBOLS=y, changes the file symbols present
> in the resulting object. We still have the "object file name" symbol,
> but now we also have "source file name with path components" symbol.
> Unfortunately, all mm/*/guest_*.o in one directory are built from the
> same source file, and thus have the same "source file name" symbol, but
> have different "object file name" symbol. We still want to be able to
> distinguish between guest_*.o in one dir, and the only way for that is
> to use the "object file name" symbol.

So where's the difference from how things work right now? The "same rune"
aspect doesn't really change - right now we also build with effectively
the same logic, just that -DGUEST_PAGING_LEVELS=... gets added. I guess
it might help if you showed (for one particular example) how the set of
file symbols changes from what we have now (with and without
CONFIG_ENFORCE_UNIQUE_SYMBOLS=y) to what there would be with your changes
to the symbols utility to what there will be with those changes.

>>> So this patch changes that ./symbols prefer the "object file
>>> name" symbol over the "source file name with path component" symbols.
>>>
>>> The new intended order of preference is:
>>>     - first object file name symbol
>>>     - first source file name with path components symbol
>>>     - last source file name without any path component symbol
>>
>> Isn't this going to lead to ambiguities again when
>> CONFIG_ENFORCE_UNIQUE_SYMBOLS? Several object files (in different
>> dirs) are named the same, after all. Static symbols with the same
>> name in such objects would hence resolve to the same kallsyms
>> name.
> 
> "object file name" symbol are only present in mm/*/guest_*.o objects,
> they all have different basenames. There is no ambiguity here.

At least not right now, I see. Could you make this aspect more explicit
by adding something like "(present only in object files produced from
multiply compiled sources)" to the first bullet point?

Jan