Re: Hidden symbol when debugging hypervisor

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

On 30/04/14 11:21, Jan Beulich wrote:
>>>> On 30.04.14 at 12:07, <george.dunlap@eu.citrix.com> wrote:
>> On 04/30/2014 10:39 AM, Juergen Gross wrote:
>>> On 30.04.2014 11:26, George Dunlap wrote:
>>>> On 04/30/2014 10:02 AM, Dietmar Hahn wrote:
>>>>> Hi,
>>>>>
>>>>> while debugging a vmcore with the crash tool I stumpled over a 
>>>>> little problem.
>>>>> I wanted to look at the "struct csched_private" of credit scheduler 
>>>>> and got
>>>>> the contents of the "struct csched_private" of credit2.
>>>>> The debug informations of the hypervisor contain 2 entries
>>>>>   <1><b185e>: Abbrev Number: 8 (DW_TAG_structure_type)
>>>>>      <b185f>   DW_AT_name        : (indirect string, offset: 0x9d8d):
>>>>> csched_private
>>>>> and
>>>>>   <1><c0677>: Abbrev Number: 25 (DW_TAG_structure_type)
>>>>>      <c0678>   DW_AT_name        : (indirect string, offset: 0x9d8d):
>>>>> csched_private
>>>>>
>>>>> The first is credit and the second credit2. It seems in the crash 
>>>>> command the
>>>>> second entry wins :-(.
>>>>>
>>>>> Maybe crash has the possibility somewhere to get access to the 
>>>>> second structure
>>>>> (I couldn't find it) but for simplicity it would be better to have 
>>>>> different
>>>>> names
>>>>> I think.
>>>>> Are there any reasons not to rename
>>>>> struct csched_private -> struct c2sched_private
>>>>> or whatever?
>>>> No reasons at all -- the naming is an artifact of development. Feel 
>>>> free to
>>>> send a patch renaming it.
>>> I tried it once: 
>>> http://lists.xen.org/archives/html/xen-devel/2013-02/msg02255.html 
>>>
>>> Jan didn't like it.
>> It looks like he was only thinking about backtraces, not about cscope or 
>> about debugging core dumps.  Jan, do you have another solution for 
>> those, or shall we go ahead and change the names?
> If you're happy with the names getting changed, so be it. I have no
> alternative suggestion. I simply would have expected that in year
> 2014 tools can deal with situations like this (i.e. find the applicable
> type rather than the first, last, or a random one). Dwarf debug info
> certainly has all the necessary information for that to happen.
>
> Jan

That is impossible in this situation (if I have understood it
correctly).  In memory, sched_priv is a void pointer, and Dietmar has
asked crash to interpret it as a 'struct csched_private'.  It is
plausible that crash could ask "do you mean a struct csched_private from
sched_credit.c or from sched_credit2.c".

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.

~Andrew