[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Hidden symbol when debugging hypervisor
On 30/04/14 15:49, Jan Beulich wrote: >>>> On 30.04.14 at 16:32, <andrew.cooper3@xxxxxxxxxx> wrote: >> On 30/04/14 15:16, Jan Beulich wrote: >>>>>> On 30.04.14 at 16:08, <andrew.cooper3@xxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |