From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Hidden symbol when debugging hypervisor Date: Wed, 30 Apr 2014 15:08:07 +0100 Message-ID: <536103C7.7040800@citrix.com> References: <2039026.XfIYG36Q6e@amur> <5360C1DC.9020707@eu.citrix.com> <5360C4D3.3010000@ts.fujitsu.com> <5360CB60.7000704@eu.citrix.com> <5360EAB7020000780000DB75@g0-1-119.ukb-fw-asa.gns.novell.com> <5360DE77.7060509@citrix.com> <536113DD020000780000DC7D@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <536113DD020000780000DC7D@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 Cc: George Dunlap , Juergen Gross , Dietmar Hahn , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 30/04/14 14:16, Jan Beulich wrote: >>>> On 30.04.14 at 13:28, wrote: >> On 30/04/14 11:21, Jan Beulich wrote: >> I have encountered similar problems generating stack traces with the Xen >> Crashdump Analyser, which only has System.map available. >> >> xen.git/xen$ cat System.map | cut -d ' ' -f 3 | sort | uniq -d | wc -l >> 78 >> >> Having duplicate symbol names for different symbols is confusing at the >> very least, and trivial to avoid. I reckon that most if not all of >> those 78 duplicate symbols can, and should be, deduplicated. Renaming >> credit -> credit2 will amend about 1/4 of that list. > For the crash dump analyzer, I can't see why it shouldn't be able to > consume the symbol table from elf-syms or elf.efi instead of the > (reduced) System.map. Because it mostly runs on a systems without the debuginfo rpms installed. Furthermore, it needs to fit in a 64MB crash region with the crash kernel and initrd as well (although this is more flexible). > > And for Xen generated stack traces I think I already said that this has > been on my todo list for quite some time, pending no more important > things to deal with, yet not to follow what you suggest, but to make > Xen consume its own ELF/COFF symbol table instead of the (again > reduced) one generated by tools/symbols. > > My main rationale here is that within a source file having prefix-less > names is not only fine, but preferable (less typing, less needless line > wrapping), and hence only global symbols need to be fully > disambiguated. > > Jan >>From a coding point of view, certainly. >>From a debugging point of view, I completely disagree. From a stack trace, you want to be able to identify the function absolutely. Currently, finding "csched_schedule()" in a stack trace still means that I have to work out which scheduler is actually in use. With a cpupool using credit1 and a cpupool using credit2, this can be very difficult after-the-fact. When stack traces have access to static symbol names, the only concept of 'non-global' which actually exists are inlined functions. ~Andrew