[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Hidden symbol when debugging hypervisor
On 30/04/14 11:21, Jan Beulich wrote: >>>> On 30.04.14 at 12:07, <george.dunlap@xxxxxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |