From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Hidden symbol when debugging hypervisor Date: Wed, 30 Apr 2014 15:57:13 +0100 Message-ID: <53610F49.9050704@eu.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> <536103C7.7040800@citrix.com> <536121E6020000780000DD3A@mail.emea.novell.com> <53610969.9060609@citrix.com> <5361298A020000780000DDC0@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5361298A020000780000DDC0@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 , Andrew Cooper Cc: Juergen Gross , Dietmar Hahn , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 04/30/2014 03:49 PM, Jan Beulich wrote: >>>> On 30.04.14 at 16:32, wrote: >> On 30/04/14 15:16, Jan Beulich wrote: >>>>>> On 30.04.14 at 16:08, wrote: >>>> Furthermore, it needs to fit in a 64MB crash region with the crash >>>> kernel and initrd as well (although this is more flexible). >>> Why would the symbol table need to be in the crash region? >> It wouldn't (necessarily), but is certainly less overhead to have the >> text symbol table in memory than all of the debugging symbols. > I never talked about debug info, but just about the ELF/COFF > symbol table. I'm not sure that's much larger than the nm output, > especially when first tidied of useless (e.g. machine generated) > symbols. > >>>> 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. >>> How would "common/sched_credit.c:schedule" (with the pointless >>> prefix already dropped) be ambiguous? >> That wouldn't, but would we really want full paths in stack traces? > I'm feeling confused - first you ask for names to be distinguishable, > and then you ask whether we would want this? Rather than having > every contributor take care for local symbols to be unique across the > tree, we _should_ leverage information that is available to achieve > the same goal without impact on source size and readability. > > And no, I definitely don't want full paths, I want relative (to > $(BASEDIR)) ones. I think "relative to $(BASEDIR)" is what Andrew meant. In any case, you're adding typically a minimum of 10 characters, worst case a lot more, to *every single* line in the stack trace, just so that you can disambiguate a handful of cases where there may be a name collision. Doestn't it make more sense for the programmers to detect when there's a name collision and add a sensibly small prefix to the symbol? It would certainly be nice to be able to remove all the "csched_" prefixes from the credit and credit2 codebases; but we do a lot more debugging than we do coding, so that has to take priority. -George