Re: [PATCH v1 1/5] xsplice: Design document.

["Jan Beulich" <JBeulich@suse.com>]

>>> On 16.09.15 at 23:01, <konrad.wilk@oracle.com> wrote:
> +### Symbol names
> +
> +
> +Xen as it is now, has a couple of non-unique symbol names which will
> +make runtime symbol identification hard.  Sometimes, static symbols
> +simply have the same name in C files, sometimes such symbols get
> +included via header files, and some C files are also compiled
> +multiple times and linked under different names (guest_walk.c).
> +
> +As such we need to modify the linker to make sure that the symbol
> +table qualifies also symbols by their source file name.
> +
> +For the awkward situations in which C-files are compiled multiple
> +times patches we would need to some modification in the Xen code.
> +
> +
> +The convention for file-type symbols (that would allow to map many
> +symbols to their compilation unit) says that only the basename (i.e.,
> +without directories) is embedded.  This creates another layer of
> +confusion for duplicate file names in the build tree.
> +
> +That would have to be resolved.

I'm working on this, btw. From what I can tell after some
investigation over the weekend we probably don't even need to
fully overhaul the current symbol handling logic, we just need to
pass different options to nm and alter processing its output
accordingly. The cumbersome case (but that would have been so
also with the originally considered full symbol table approach) will
be xen.efi, but I guess I'll first try to deal with this on the binutils
side.

Jan