Re: Hidden symbol when debugging hypervisor

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

On 30/04/14 14:16, Jan Beulich wrote:
>>>> On 30.04.14 at 13:28, <andrew.cooper3@citrix.com> wrote:
>> On 30/04/14 11:21, Jan Beulich wrote:
>> I have encountered similar problems generating stack traces with the Xen
>> Crashdump Analyser, which only has System.map available.
>>
>> xen.git/xen$ cat System.map | cut -d ' ' -f 3 | sort | uniq -d | wc -l
>> 78
>>
>> Having duplicate symbol names for different symbols is confusing at the
>> very least, and trivial to avoid.  I reckon that most if not all of
>> those 78 duplicate symbols can, and should be, deduplicated.  Renaming
>> credit -> credit2 will amend about 1/4 of that list.
> For the crash dump analyzer, I can't see why it shouldn't be able to
> consume the symbol table from elf-syms or elf.efi instead of the
> (reduced) System.map.

Because it mostly runs on a systems without the debuginfo rpms installed.

Furthermore, it needs to fit in a 64MB crash region with the crash
kernel and initrd as well (although this is more flexible).

>
> And for Xen generated stack traces I think I already said that this has
> been on my todo list for quite some time, pending no more important
> things to deal with, yet not to follow what you suggest, but to make
> Xen consume its own ELF/COFF symbol table instead of the (again
> reduced) one generated by tools/symbols.
>
> My main rationale here is that within a source file having prefix-less
> names is not only fine, but preferable (less typing, less needless line
> wrapping), and hence only global symbols need to be fully
> disambiguated.
>
> Jan

>From a coding point of view, certainly.

>From a debugging point of view, I completely disagree.  From a stack
trace, you want to be able to identify the function absolutely. 
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.

When stack traces have access to static symbol names, the only concept
of 'non-global' which actually exists are inlined functions.

~Andrew