From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Pohlack Subject: Re: [RFC v2] xSplice design Date: Mon, 08 Jun 2015 10:34:44 +0200 Message-ID: <557553A4.5000104@amazon.com> References: <20150515194440.GA24313@l.oracle.com> <555CA418.6080707@amazon.com> <20150605150029.GC10207@l.oracle.com> <5571DBE602000078000817AA@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z1sWQ-0001QY-03 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2015 08:35:06 +0000 In-Reply-To: <5571DBE602000078000817AA@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Konrad Rzeszutek Wilk Cc: Elena Ufimtseva , jeremy@goop.org, hanweidong@huawei.com, john.liuqiming@huawei.com, Paul Voccio , xen-devel@lists.xenproject.org, Daniel Kiper , Major Hayden , liuyingdong@huawei.com, aliguori@amazon.com, konrad@darnok.org, lars.kurth@citrix.com, Steven Wilson , peter.huangpeng@huawei.com, msw@amazon.com, xiantao.zxt@alibaba-inc.com, Rick Harris , boris.ostrovsky@oracle.com, Josh Kearney , jinsong.liu@alibaba-inc.com, Antony Messerli , fanhenglong@huawei.com, andrew.cooper3@citrix.com List-Id: xen-devel@lists.xenproject.org On 05.06.2015 17:27, Jan Beulich wrote: >>>> On 05.06.15 at 17:00, 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