Re: [Xen-devel] [RFC v2] xSplice design

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.06.15 at 10:34, <mpohlack@xxxxxxxxxx> wrote:
> On 05.06.2015 17:27, Jan Beulich wrote:
>>>>> On 05.06.15 at 17:00, <konrad.wilk@xxxxxxxxxx> wrote:
>>> On Wed, May 20, 2015 at 05:11:20PM +0200, Martin Pohlack wrote:
>>>> * 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).  I
>>>>   think the Linux kernel solves this by aiming at unique symbol names
>>>>   even for local symbols.
>>>>
>>>>   nm xen-syms | cut -f3- -d\  | sort | uniq -c | sort -nr | head
>>>
>>> Oh my. Looks like a couple of prepartion patches will be in order!
>> 
>> Just because nm doesn't express this doesn't mean we have to
>> special case them: In ELF (and in COFF too, which is relevant as
>> long as xen.efi still remains to be a separate binary) static symbols
>> can easily be qualified by their source or object file name - the
>> symbol table certainly has that information available. As said on
>> the hackathon, our current kallsyms mechanism - using nm output -
>> suffers from this too, yet I personally view it as rather bad practice
>> to add a globally unique prefix to local symbol names. Instead, as
>> also said there, we should switch to consuming the full ELF symbol
>> table. That's been on my todo list for two years or more - if only I
>> would ever get the time to do things like that...
> 
> Hmm, in my experience, you have file-type symbols in the symbol table
> that refer to source-code files and you have source-file references in
> the dwarf debug information.
> 
> I have *not* seen references to object-files in either place

The linker can insert such. But the case likely isn't of interest in
our scenario anyway.

> and as some
> C-files are compiled multiple times in Xen (guest_walk.c), the mapping
> is not unique.

And I suppose there are always going to be cases where manual
intervention is required. All we can aim for is making as little of such
necessary as possible.

> Further, as soon as non-trivial linker scripts are used, the symbol
> ordering in the final xen-syms does not necessarily reflect original
> object-file contents anymore.

But the linker should ensure that static symbols don't lose their
association with the respective STT_FILE symbol.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel