[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2] xSplice design
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |