From mboxrd@z Thu Jan  1 00:00:00 1970
From: Don Slutz <dslutz@verizon.com>
Subject: Re: [PATCH v2 07/12] xenctx: Add stack addr to call
	trace.
Date: Thu, 7 Nov 2013 10:06:18 -0500
Message-ID: <527BAC6A.9080109@terremark.com>
References: <1383768500-4245-1-git-send-email-dslutz@terremark.com>
	<1383768500-4245-8-git-send-email-dslutz@terremark.com>
	<1383828610.32399.32.camel@kazak.uk.xensource.com>
	<527BA4F6.6030804@terremark.com>
	<1383835451.32399.47.camel@kazak.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1383835451.32399.47.camel@kazak.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, George Dunlap <george.dunlap@eu.citrix.com>, Don Slutz <Don@CloudSwitch.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Don Slutz <dslutz@verizon.com>, xen-devel@lists.xen.org, Jan Beulich <JBeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

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