[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.