Re: Hidden symbol when debugging hypervisor

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 30/04/14 15:49, Jan Beulich wrote:
>>>> On 30.04.14 at 16:32, <andrew.cooper3@citrix.com> wrote:
>> On 30/04/14 15:16, Jan Beulich wrote:
>>>>>> On 30.04.14 at 16:08, <andrew.cooper3@citrix.com> 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