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:58:09 +0100 Message-ID: <53610F81.503@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" 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 Cc: George Dunlap , Juergen Gross , Dietmar Hahn , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 30/04/14 15:49, 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. Ah ok - It would certainly be interesting to see. > >>>> 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. > > Jan > I am just concerned that long paths and long function names might start exceeding the width of a console, even if the path has $(XEN_ROOT)/xen/ stripped off the front. ~Andrew