[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Hidden symbol when debugging hypervisor
>>> 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. >>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |