Re: [Xen-devel] Hidden symbol when debugging hypervisor

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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