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

[Anthony PERARD <anthony.perard@citrix.com>]

On Thu, Apr 16, 2020 at 04:22:05PM +0200, Jan Beulich wrote:
> 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.

The logic to build objects from C files changed in 81ecb38b83b0 ("build:
provide option to disambiguate symbol names"), with objects build with
__OBJECT_FILE__ explicitly left alone. So the logic is different now (at
least when CONFIG_ENFORCE_UNIQUE_SYMBOLS=y).

I did add the example of building arch/x86/mm/guest_walk_2.o to the
commit message, reworded below:

For example, when building arch/x86/mm/guest_walk_2.o from guest_walk.c,
this would be the difference of file symbol present in the object when
building with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y:

(1) Currently we have those two file symbols:
    guest_walk.c
    guest_walk_2.o
(2) When building with the same rune, we will have:
    arch/x86/mm/guest_walk.c
    guest_walk_2.o

The order in which those symbols are present may be different. Building
without CONFIG_ENFORCE_UNIQUE_SYMBOLS will result in (1).


> >>> 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?

Will do.

-- 
Anthony PERARD