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

[Martin Pohlack <mpohlack@xxxxxxxxxx>]

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

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.

I might be missing some mechanism here?

Martin

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