Re: [PATCH v2 07/12] xenctx: Add stack addr to call trace.

[Don Slutz <dslutz@verizon.com>]

On 11/07/13 09:44, Ian Campbell wrote:
> On Thu, 2013-11-07 at 09:34 -0500, Don Slutz wrote:
>> On 11/07/13 07:50, Ian Campbell wrote:
>>
>>> On Wed, 2013-11-06 at 15:08 -0500, Don Slutz wrote:
>>>> From: Don Slutz <Don@CloudSwitch.com>
>>> Can you give an example of the output please.
>> Here it is (With all patches active):
>>            cs: 0010 @ 0000000000000000
>>                     /ffffffff(a9b)
> Is the ugly wrapping real or email whitespace damage?
Real. The way it currently looks is clearer with a symbol.  Doing both 
the address and symbol and other data is not simple. I was trying to 
keep things aligned which is very hard with variable length output. 
xen-hvmctx's output:

              cs 0x00000010 (0x0000000000000000 + 0xffffffff / 0x00a9b)

Using + to indicate a limit is not so clear either.



Things like idt are simpler.
      idt: ffffffff8042c000/fff idt_table


>>            ss: 0018 @ 0000000000000000
>>                     /ffffffff(c93)
>>            ds: 0018 @ 0000000000000000
>>                     /ffffffff(c93)
>>            es: 0018 @ 0000000000000000
>>                     /ffffffff(c93)
>>            fs: 0000 @ 0000000000000000
>>                     /ffffffff(c00)
>>            gs: 0000 @ ffffffff803ac000\0000000000000000 boot_cpu_pda\
>>                     /ffffffff(c00)
Should this be split into "gs" and "shadow gs"?
> [...]
>>> What is "stack address" is it the base of the function's stack frame
>>> perhaps? Or maybe the top? Or maybe the framepointer?
>> It is the address of the stack "word".
> I'm afraid I am non the wiser.
>
> Ian.
Does just:

   ffffffff803ddf90: ffffffff80048d19 0000000000200800 .......... .....
vs
   ffffffff803ddf90:  [<ffffffff80048d19>] cpu_idle+0x95

help?  The start of the line is the same.
     -Don