[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |