* [PATCH v5 01/17] xenctx: clean up usage output
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
@ 2014-03-20 19:06 ` Don Slutz
2014-03-21 14:21 ` Ian Campbell
2014-03-20 19:06 ` [PATCH v5 02/17] xenctx: Clean up stack trace when hypercall_page not in symbol table Don Slutz
` (16 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:06 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Ian Jackson,
Don Slutz, Jan Beulich
Fix usage formatting to be all the same.
Fix usage display of default --kernel-start for 64 bit.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
---
tools/xentrace/xenctx.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index 7275a00..97c6197 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -823,15 +823,16 @@ static void usage(void)
printf("options:\n");
printf(" -f, --frame-pointers\n");
- printf(" assume the kernel was compiled with\n");
- printf(" frame pointers.\n");
+ printf(" assume the kernel was compiled with\n");
+ printf(" frame pointers.\n");
printf(" -s SYMTAB, --symbol-table=SYMTAB\n");
- printf(" read symbol table from SYMTAB.\n");
- printf(" -S --stack-trace print a complete stack trace.\n");
- printf(" -k, --kernel-start\n");
- printf(" set user/kernel split. (default 0xc0000000)\n");
- printf(" -a --all display more registers\n");
- printf(" -C --all-vcpus print info for all vcpus\n");
+ printf(" read symbol table from SYMTAB.\n");
+ printf(" -S, --stack-trace print a complete stack trace.\n");
+ printf(" -k KADDR, --kernel-start=KADDR\n");
+ printf(" set user/kernel split. (default 0x"FMT_32B_WORD")\n",
+ kernel_start);
+ printf(" -a, --all display more registers\n");
+ printf(" -C, --all-vcpus print info for all vcpus\n");
}
int main(int argc, char **argv)
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* [PATCH v5 02/17] xenctx: Clean up stack trace when hypercall_page not in symbol table
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
2014-03-20 19:06 ` [PATCH v5 01/17] xenctx: clean up usage output Don Slutz
@ 2014-03-20 19:06 ` Don Slutz
2014-03-20 19:06 ` [PATCH v5 03/17] xenctx: Add -n (--display-stack-pages) option to output larger stack Don Slutz
` (15 subsequent siblings)
17 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:06 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Don Slutz,
Ian Jackson, Jan Beulich
From: Don Slutz <Don@CloudSwitch.com>
Before:
Call Trace:
[<ffffffff8006b2b0>] default_idle+0x29 <--
[<ffffffff80048d19>] cpu_idle+0x95
[<ffffffff803e7801>] start_kernel+0x220
[<0000000000000000>] startup_64+0x80000000
[<ffffffff803e722f>] x86_64_start_kernel+0x22f
[<0000000000000000>] startup_64+0x80000000
[<0000000000000000>] startup_64+0x80000000
[<0000000000000000>] startup_64+0x80000000
[<0000000000000000>] startup_64+0x80000000
After:
Call Trace:
[<ffffffff8006b2b0>] default_idle+0x29 <--
[<ffffffff80048d19>] cpu_idle+0x95
[<ffffffff803e7801>] start_kernel+0x220
[<ffffffff803e722f>] x86_64_start_kernel+0x22f
Signed-off-by: Don Slutz <Don@CloudSwitch.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
---
tools/xentrace/xenctx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index 97c6197..42a47f3 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -85,8 +85,9 @@ static int is_kernel_text(guest_word_t addr)
if (addr >= kernel_stext &&
addr <= kernel_etext)
return 1;
- if (addr >= kernel_hypercallpage &&
- addr <= kernel_hypercallpage + 4096)
+ if ( kernel_hypercallpage &&
+ (addr >= kernel_hypercallpage &&
+ addr <= kernel_hypercallpage + 4096) )
return 1;
if (addr >= kernel_sinittext &&
addr <= kernel_einittext)
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* [PATCH v5 03/17] xenctx: Add -n (--display-stack-pages) option to output larger stack
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
2014-03-20 19:06 ` [PATCH v5 01/17] xenctx: clean up usage output Don Slutz
2014-03-20 19:06 ` [PATCH v5 02/17] xenctx: Clean up stack trace when hypercall_page not in symbol table Don Slutz
@ 2014-03-20 19:06 ` Don Slutz
2014-03-21 14:29 ` Ian Campbell
2014-03-20 19:06 ` [PATCH v5 04/17] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines) Don Slutz
` (14 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:06 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Don Slutz,
Ian Jackson, Jan Beulich
From: Don Slutz <Don@CloudSwitch.com>
Important: This is the stack size to display not the configured
stack size.
Note: use with caution (easy to get garbage).
Below is various pictures of a configured 3 page stack, and where
the SP currently is. Each box is a page.
+------------------+
| |
| |
| |
| |
| |
+------------------+
| |
| |
| |
| |
| |
+------------------+
| |
| |
| |
SP --> | |
| |
+------------------+
Display using "-n 1" since the used stack pages is 1.
+------------------+
| |
| |
| |
| |
| |
+------------------+
| |
SP --> | |
| |
| |
| |
+------------------+
| |
| |
| |
| |
| |
+------------------+
Display using "-n 2" since the used stack pages is 2.
+------------------+
| |
| |
| |
| |
SP --> | |
+------------------+
| |
| |
| |
| |
| |
+------------------+
| |
| |
| |
| |
| |
+------------------+
Display using "-n 3" since the used stack pages is 3.
Signed-off-by: Don Slutz <Don@CloudSwitch.com>
---
v5: Adjust option to -n, --display-stack-pages. Adjust usage message.
tools/xentrace/xenctx.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index 42a47f3..caa8899 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -35,6 +35,7 @@ static struct xenctx {
int frame_ptrs;
int stack_trace;
int disp_all;
+ int multiple_pages;
int all_vcpus;
int self_paused;
xc_dominfo_t dominfo;
@@ -664,6 +665,8 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
stack_limit = ((stack_pointer(ctx) + XC_PAGE_SIZE)
& ~((guest_word_t) XC_PAGE_SIZE - 1));
+ if ( xenctx.multiple_pages > 1 )
+ stack_limit += (xenctx.multiple_pages - 1) * XC_PAGE_SIZE;
printf("\n");
printf("Stack:\n");
for (i=1; i<5 && stack < stack_limit; i++) {
@@ -834,18 +837,22 @@ static void usage(void)
kernel_start);
printf(" -a, --all display more registers\n");
printf(" -C, --all-vcpus print info for all vcpus\n");
+ printf(" -n PAGES, --display-stack-pages=PAGES\n");
+ printf(" Display N pages from the stack pointer.\n");
+ printf(" Note: use with caution (easy to get garbage).\n");
}
int main(int argc, char **argv)
{
int ch;
int ret;
- static const char *sopts = "fs:hak:SC";
+ static const char *sopts = "fs:hak:SCn:";
static const struct option lopts[] = {
{"stack-trace", 0, NULL, 'S'},
{"symbol-table", 1, NULL, 's'},
{"frame-pointers", 0, NULL, 'f'},
{"kernel-start", 1, NULL, 'k'},
+ {"display-stack-pages", 0, NULL, 'n'},
{"all", 0, NULL, 'a'},
{"all-vcpus", 0, NULL, 'C'},
{"help", 0, NULL, 'h'},
@@ -869,6 +876,9 @@ int main(int argc, char **argv)
case 'a':
xenctx.disp_all = 1;
break;
+ case 'n':
+ xenctx.multiple_pages = strtol(optarg, NULL, 0);
+ break;
case 'C':
xenctx.all_vcpus = 1;
break;
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v5 03/17] xenctx: Add -n (--display-stack-pages) option to output larger stack
2014-03-20 19:06 ` [PATCH v5 03/17] xenctx: Add -n (--display-stack-pages) option to output larger stack Don Slutz
@ 2014-03-21 14:29 ` Ian Campbell
2014-03-22 20:49 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 14:29 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
> From: Don Slutz <Don@CloudSwitch.com>
>
> Important: This is the stack size to display not the configured
> stack size.
>
> Note: use with caution (easy to get garbage).
>
> Below is various pictures of a configured 3 page stack, and where
> the SP currently is. Each box is a page.
>
> +------------------+
> | |
> | |
> | |
> | |
> | |
> +------------------+
> | |
> | |
> | |
> | |
> | |
> +------------------+
> | |
> | |
> | |
> SP --> | |
> | |
> +------------------+
>
> Display using "-n 1" since the used stack pages is 1.
Like George I am also confused by what these diagrams are trying to show
me, and even having read your response to him I'm confused.
Why is the SP moving around in these pictures? I understood that this
option was changing what was considered to be the limit of the stack,
not the stack pointer itself, so shouldn't it be the base of the stack
which is moving around?
Perhaps if you had the diagram once and along side it had columns
showing what is printed for each -n value as a range
e.g.
None -n 1
+------------------+ +
| | |
| | |
| | |
| | |
| | |
+------------------+ + |
| | | |
SP --> | | + +
| |
| |
| |
+------------------+
(or whatever the reality is)
[...]
> Signed-off-by: Don Slutz <Don@CloudSwitch.com>
Out of date?
> ---
> v5: Adjust option to -n, --display-stack-pages. Adjust usage message.
>
> tools/xentrace/xenctx.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
> index 42a47f3..caa8899 100644
> --- a/tools/xentrace/xenctx.c
> +++ b/tools/xentrace/xenctx.c
> @@ -35,6 +35,7 @@ static struct xenctx {
> int frame_ptrs;
> int stack_trace;
> int disp_all;
> + int multiple_pages;
> int all_vcpus;
> int self_paused;
> xc_dominfo_t dominfo;
> @@ -664,6 +665,8 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
>
> stack_limit = ((stack_pointer(ctx) + XC_PAGE_SIZE)
> & ~((guest_word_t) XC_PAGE_SIZE - 1));
> + if ( xenctx.multiple_pages > 1 )
> + stack_limit += (xenctx.multiple_pages - 1) * XC_PAGE_SIZE;
"multiple_pages" sounds like a boolean to me, you seem to use it as
"extra_pages", but why not just call it nr_stack_pages, initialise it to
1 and override it with --display-stack-pages.
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 03/17] xenctx: Add -n (--display-stack-pages) option to output larger stack
2014-03-21 14:29 ` Ian Campbell
@ 2014-03-22 20:49 ` Don Slutz
2014-03-24 10:39 ` Ian Campbell
0 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-22 20:49 UTC (permalink / raw)
To: Ian Campbell
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
Don Slutz, xen-devel, Jan Beulich
On 03/21/14 10:29, Ian Campbell wrote:
> On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
>> From: Don Slutz <Don@CloudSwitch.com>
>>
>> Important: This is the stack size to display not the configured
>> stack size.
>>
>> Note: use with caution (easy to get garbage).
>>
>> Below is various pictures of a configured 3 page stack, and where
>> the SP currently is. Each box is a page.
>>
>> +------------------+
>> | |
>> | |
>> | |
>> | |
>> | |
>> +------------------+
>> | |
>> | |
>> | |
>> | |
>> | |
>> +------------------+
>> | |
>> | |
>> | |
>> SP --> | |
>> | |
>> +------------------+
>>
>> Display using "-n 1" since the used stack pages is 1.
> Like George I am also confused by what these diagrams are trying to show
> me, and even having read your response to him I'm confused.
Let me try again.
Here is real output for a kernel with 4 page stacks:
tools/xentrace/xenctx -s ~/zzm 4 -n 1
rip: ffffffff81346876 io_serial_in+0x16
flags: 00000002 nz
rsp: ffff8800385a5ab8
rax: 000000000000006f rcx: 0000000000000000 rdx: 00000000000003fd
rbx: ffffffff81ff8f00 rsi: 0000000000000005 rdi: ffffffff81ff8f00
rbp: ffff8800385a5ab8 r8: ffffffff81c03a10 r9: 0000000000000080
r10: 0000000000000005 r11: 0000000000000046 r12: 000000000000270f
r13: 0000000000000020 r14: 0000000000000025 r15: ffffffff81346f20
cs: 0010 ss: 0018 ds: 0000 es: 0000
fs: 0000 @ 00007f07972f3700
gs: 0000 @ ffff88000b400000/0000000000000000/
Code (instr addr ffffffff81346876)
48 89 e5 0f 1f 44 00 00 0f b6 4f 41 0f b7 57 08 d3 e6 01 f2 ec <0f> b6
c0 c9 c3 0f 1f 44 00 00 55
Stack:
ffff8800385a5ae8 ffffffff81346e64 ffffffff81ff8f00 0000000000000072
0000000000000064 0000000000000025 ffff8800385a5b08 ffffffff81346f46
ffffffff81e3e430 ffffffff81ff8f00 ffff8800385a5b48 ffffffff813428de
ffffffff8100bc0e 0000000000000000 ffffffff81ff8f00 0000000000000001
0000000000000064 ffffffff81e3e40c ffff8800385a5b98 ffffffff813472ad
Call Trace:
[<ffffffff81346876>] io_serial_in+0x16 <--
[<ffffffff81346e64>] wait_for_xmitr+0x24
[<ffffffff81346f46>] serial8250_console_putchar+0x26
[<ffffffff813428de>] uart_console_write+0x3e
[<ffffffff8100bc0e>] apic_timer_interrupt+0xe
[<ffffffff813472ad>] serial8250_console_write+0xbd
[<ffffffff8106b8f5>] __call_console_drivers+0x75
[<ffffffff8106b95a>] _call_console_drivers+0x4a
[<ffffffff8106be6e>] release_console_sem+0x4e
[<ffffffff8106c628>] vprintk+0x248
[<ffffffff814fd363>] printk+0x41
tools/xentrace/xenctx -s ~/zzm 4 -n 2
rip: ffffffff81346876 io_serial_in+0x16
flags: 00000002 nz
rsp: ffff8800385a5ab8
rax: 000000000000006f rcx: 0000000000000000 rdx: 00000000000003fd
rbx: ffffffff81ff8f00 rsi: 0000000000000005 rdi: ffffffff81ff8f00
rbp: ffff8800385a5ab8 r8: ffffffff81c03a10 r9: 0000000000000080
r10: 0000000000000005 r11: 0000000000000046 r12: 000000000000270f
r13: 0000000000000020 r14: 0000000000000025 r15: ffffffff81346f20
cs: 0010 ss: 0018 ds: 0000 es: 0000
fs: 0000 @ 00007f07972f3700
gs: 0000 @ ffff88000b400000/0000000000000000/
Code (instr addr ffffffff81346876)
48 89 e5 0f 1f 44 00 00 0f b6 4f 41 0f b7 57 08 d3 e6 01 f2 ec <0f> b6
c0 c9 c3 0f 1f 44 00 00 55
Stack:
ffff8800385a5ae8 ffffffff81346e64 ffffffff81ff8f00 0000000000000072
0000000000000064 0000000000000025 ffff8800385a5b08 ffffffff81346f46
ffffffff81e3e430 ffffffff81ff8f00 ffff8800385a5b48 ffffffff813428de
ffffffff8100bc0e 0000000000000000 ffffffff81ff8f00 0000000000000001
0000000000000064 ffffffff81e3e40c ffff8800385a5b98 ffffffff813472ad
Call Trace:
[<ffffffff81346876>] io_serial_in+0x16 <--
[<ffffffff81346e64>] wait_for_xmitr+0x24
[<ffffffff81346f46>] serial8250_console_putchar+0x26
[<ffffffff813428de>] uart_console_write+0x3e
[<ffffffff8100bc0e>] apic_timer_interrupt+0xe
[<ffffffff813472ad>] serial8250_console_write+0xbd
[<ffffffff8106b8f5>] __call_console_drivers+0x75
[<ffffffff8106b95a>] _call_console_drivers+0x4a
[<ffffffff8106be6e>] release_console_sem+0x4e
[<ffffffff8106c628>] vprintk+0x248
[<ffffffff814fd363>] printk+0x41
tools/xentrace/xenctx -s ~/zzm 4 -n 3
rip: ffffffff81346876 io_serial_in+0x16
flags: 00000002 nz
rsp: ffff8800385a5ab8
rax: 000000000000006f rcx: 0000000000000000 rdx: 00000000000003fd
rbx: ffffffff81ff8f00 rsi: 0000000000000005 rdi: ffffffff81ff8f00
rbp: ffff8800385a5ab8 r8: ffffffff81c03a10 r9: 0000000000000080
r10: 0000000000000005 r11: 0000000000000046 r12: 000000000000270f
r13: 0000000000000020 r14: 0000000000000025 r15: ffffffff81346f20
cs: 0010 ss: 0018 ds: 0000 es: 0000
fs: 0000 @ 00007f07972f3700
gs: 0000 @ ffff88000b400000/0000000000000000/
Code (instr addr ffffffff81346876)
48 89 e5 0f 1f 44 00 00 0f b6 4f 41 0f b7 57 08 d3 e6 01 f2 ec <0f> b6
c0 c9 c3 0f 1f 44 00 00 55
Stack:
ffff8800385a5ae8 ffffffff81346e64 ffffffff81ff8f00 0000000000000072
0000000000000064 0000000000000025 ffff8800385a5b08 ffffffff81346f46
ffffffff81e3e430 ffffffff81ff8f00 ffff8800385a5b48 ffffffff813428de
ffffffff8100bc0e 0000000000000000 ffffffff81ff8f00 0000000000000001
0000000000000064 ffffffff81e3e40c ffff8800385a5b98 ffffffff813472ad
Call Trace:
[<ffffffff81346876>] io_serial_in+0x16 <--
[<ffffffff81346e64>] wait_for_xmitr+0x24
[<ffffffff81346f46>] serial8250_console_putchar+0x26
[<ffffffff813428de>] uart_console_write+0x3e
[<ffffffff8100bc0e>] apic_timer_interrupt+0xe
[<ffffffff813472ad>] serial8250_console_write+0xbd
[<ffffffff8106b8f5>] __call_console_drivers+0x75
[<ffffffff8106b95a>] _call_console_drivers+0x4a
[<ffffffff8106be6e>] release_console_sem+0x4e
[<ffffffff8106c628>] vprintk+0x248
[<ffffffff814fd363>] printk+0x41
[<ffffffff8100204c>] do_one_initcall+0x3c
[<ffffffff810b0eb1>] sys_init_module+0xe1
[<ffffffff8100b0f2>] system_call_fastpath+0x16
As you can see from above, only the last 3 lines show up for "-n 3"
>
> Why is the SP moving around in these pictures? I understood that this
> option was changing what was considered to be the limit of the stack,
> not the stack pointer itself, so shouldn't it be the base of the stack
> which is moving around?
These are pictures of the same stack at 3 different times. And as you
can see
from above, this option does change the stack limit.
>
> Perhaps if you had the diagram once and along side it had columns
> showing what is printed for each -n value as a range
>
> e.g.
> None -n 1
> +------------------+ +
> | | |
> | | |
> | | |
> | | |
> | | |
> +------------------+ + |
> | | | |
> SP --> | | + +
> | |
> | |
> | |
> +------------------+
>
> (or whatever the reality is)
>
> [...]
I will add this. And some statement about each picture is for a
different time.
>> Signed-off-by: Don Slutz <Don@CloudSwitch.com>
> Out of date?
Yes, and no. Both email continue to work. I will update it.
>> ---
>> v5: Adjust option to -n, --display-stack-pages. Adjust usage message.
>>
>> tools/xentrace/xenctx.c | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
>> index 42a47f3..caa8899 100644
>> --- a/tools/xentrace/xenctx.c
>> +++ b/tools/xentrace/xenctx.c
>> @@ -35,6 +35,7 @@ static struct xenctx {
>> int frame_ptrs;
>> int stack_trace;
>> int disp_all;
>> + int multiple_pages;
>> int all_vcpus;
>> int self_paused;
>> xc_dominfo_t dominfo;
>> @@ -664,6 +665,8 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
>>
>> stack_limit = ((stack_pointer(ctx) + XC_PAGE_SIZE)
>> & ~((guest_word_t) XC_PAGE_SIZE - 1));
>> + if ( xenctx.multiple_pages > 1 )
>> + stack_limit += (xenctx.multiple_pages - 1) * XC_PAGE_SIZE;
> "multiple_pages" sounds like a boolean to me, you seem to use it as
> "extra_pages", but why not just call it nr_stack_pages, initialise it to
> 1 and override it with --display-stack-pages.
I will adjust the internal name also. No idea why I did not do so when
to option name was changed.
-Don Slutz
> Ian.
>
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 03/17] xenctx: Add -n (--display-stack-pages) option to output larger stack
2014-03-22 20:49 ` Don Slutz
@ 2014-03-24 10:39 ` Ian Campbell
2014-03-24 13:26 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-24 10:39 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Sat, 2014-03-22 at 16:49 -0400, Don Slutz wrote:
> As you can see from above, only the last 3 lines show up for "-n 3"
OK.
> >
> > Why is the SP moving around in these pictures? I understood that this
> > option was changing what was considered to be the limit of the stack,
> > not the stack pointer itself, so shouldn't it be the base of the stack
> > which is moving around?
>
> These are pictures of the same stack at 3 different times. And as you
> can see
> from above, this option does change the stack limit.
There was no stack limit shown on your diagrams, only a stack pointer
which was mysteriously changing. The SP is an actual register which is a
property of the VM, changing it based on a xenctx surely doesn't make
sense! (also it is not moving by page sized increments, which is odd
even for the base, which ought to point at a page boundary surely).
> > Perhaps if you had the diagram once and along side it had columns
> > showing what is printed for each -n value as a range
> >
> > e.g.
> > None -n 1
> > +------------------+ +
> > | | |
> > | | |
> > | | |
> > | | |
> > | | |
> > +------------------+ + |
> > | | | |
> > SP --> | | + +
> > | |
> > | |
> > | |
> > +------------------+
> >
> > (or whatever the reality is)
> >
> > [...]
>
> I will add this. And some statement about each picture is for a
> different time.
Wait, what? Each picture is for a different time? How is that useful?
The point of these diagrams is surely to illustrate the effect of what
using this option would be at some fixed "snapshot" in time, adding a
second axis of variation to the pictures is just confusing.
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH v5 03/17] xenctx: Add -n (--display-stack-pages) option to output larger stack
2014-03-24 10:39 ` Ian Campbell
@ 2014-03-24 13:26 ` Don Slutz
0 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-24 13:26 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On 03/24/14 06:39, Ian Campbell wrote:
> On Sat, 2014-03-22 at 16:49 -0400, Don Slutz wrote:
>> As you can see from above, only the last 3 lines show up for "-n 3"
> OK.
>
>>> Why is the SP moving around in these pictures? I understood that this
>>> option was changing what was considered to be the limit of the stack,
>>> not the stack pointer itself, so shouldn't it be the base of the stack
>>> which is moving around?
>> These are pictures of the same stack at 3 different times. And as you
>> can see
>> from above, this option does change the stack limit.
> There was no stack limit shown on your diagrams, only a stack pointer
> which was mysteriously changing. The SP is an actual register which is a
> property of the VM, changing it based on a xenctx surely doesn't make
> sense! (also it is not moving by page sized increments, which is odd
> even for the base, which ought to point at a page boundary surely).
>
>>> Perhaps if you had the diagram once and along side it had columns
>>> showing what is printed for each -n value as a range
>>>
>>> e.g.
>>> None -n 1
>>> +------------------+ +
>>> | | |
>>> | | |
>>> | | |
>>> | | |
>>> | | |
>>> +------------------+ + |
>>> | | | |
>>> SP --> | | + +
>>> | |
>>> | |
>>> | |
>>> +------------------+
>>>
>>> (or whatever the reality is)
>>>
>>> [...]
>> I will add this. And some statement about each picture is for a
>> different time.
> Wait, what? Each picture is for a different time? How is that useful?
>
> The point of these diagrams is surely to illustrate the effect of what
> using this option would be at some fixed "snapshot" in time, adding a
> second axis of variation to the pictures is just confusing.
>
> Ian.
>
Ok, will adjust to just 1 picture.
-Don Slutz
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH v5 04/17] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines)
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (2 preceding siblings ...)
2014-03-20 19:06 ` [PATCH v5 03/17] xenctx: Add -n (--display-stack-pages) option to output larger stack Don Slutz
@ 2014-03-20 19:06 ` Don Slutz
2014-03-21 14:32 ` Ian Campbell
2014-03-20 19:06 ` [PATCH v5 05/17] xenctx: Add command line option -D (--decode-as-ascii) Don Slutz
` (13 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:06 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Ian Jackson,
Don Slutz, Jan Beulich
-b <bytes>, --bytes-per-line <bytes>
change the number of bytes per line output for Stack.
(default 32) Note: rounded to native size (4 or 8 bytes).
-l <lines>, --lines <lines>
change the number of lines output for Stack. (default 5)
Can be specified as MAX. Note: Fewer lines will be output
if Stack limit reached.
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
v5: Add defaults to disply. Accept MAX for -l.
tools/xentrace/xenctx.c | 79 +++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 67 insertions(+), 12 deletions(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index caa8899..f540b61 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -23,12 +23,16 @@
#include <string.h>
#include <inttypes.h>
#include <getopt.h>
+#include <limits.h>
#include "xenctrl.h"
#include <xen/foreign/x86_32.h>
#include <xen/foreign/x86_64.h>
#include <xen/hvm/save.h>
+#define DEFAULT_BYTES_PER_LINE 32
+#define DEFAULT_LINES 5
+
static struct xenctx {
xc_interface *xc_handle;
int domid;
@@ -36,6 +40,8 @@ static struct xenctx {
int stack_trace;
int disp_all;
int multiple_pages;
+ int bytes_per_line;
+ int lines;
int all_vcpus;
int self_paused;
xc_dominfo_t dominfo;
@@ -62,6 +68,8 @@ typedef uint64_t guest_word_t;
#define FMT_64B_WORD "%016lx"
#endif
+#define MAX_BYTES_PER_LINE 128
+
struct symbol {
guest_word_t address;
char *name;
@@ -663,25 +671,33 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
guest_word_t *p;
int i;
+ if ( width )
+ xenctx.bytes_per_line = ((xenctx.bytes_per_line + width - 1) / width) * width;
stack_limit = ((stack_pointer(ctx) + XC_PAGE_SIZE)
& ~((guest_word_t) XC_PAGE_SIZE - 1));
if ( xenctx.multiple_pages > 1 )
stack_limit += (xenctx.multiple_pages - 1) * XC_PAGE_SIZE;
printf("\n");
- printf("Stack:\n");
- for (i=1; i<5 && stack < stack_limit; i++) {
- while(stack < stack_limit && stack < stack_pointer(ctx) + i*32) {
- p = map_page(ctx, vcpu, stack);
- if (!p)
- return -1;
- word = read_stack_word(p, width);
- printf(" ");
- print_stack_word(word, width);
- stack += width;
+ if ( xenctx.lines )
+ {
+ printf("Stack:\n");
+ for (i = 1; i < xenctx.lines + 1 && stack < stack_limit; i++)
+ {
+ while ( stack < stack_limit &&
+ stack < stack_pointer(ctx) + i * xenctx.bytes_per_line )
+ {
+ p = map_page(ctx, vcpu, stack);
+ if ( !p )
+ return -1;
+ word = read_stack_word(p, width);
+ printf(" ");
+ print_stack_word(word, width);
+ stack += width;
+ }
+ printf("\n");
}
printf("\n");
}
- printf("\n");
if(xenctx.stack_trace)
printf("Stack Trace:\n");
@@ -840,19 +856,30 @@ static void usage(void)
printf(" -n PAGES, --display-stack-pages=PAGES\n");
printf(" Display N pages from the stack pointer.\n");
printf(" Note: use with caution (easy to get garbage).\n");
+ printf(" -b <bytes>, --bytes-per-line <bytes>\n");
+ printf(" change the number of bytes per line output for Stack.\n");
+ printf(" (default %d) Note: rounded to native size (4 or 8 bytes).\n",
+ DEFAULT_BYTES_PER_LINE);
+ printf(" -l <lines>, --lines <lines>\n");
+ printf(" change the number of lines output for Stack. (default %d)\n",
+ DEFAULT_LINES);
+ printf(" Can be specified as MAX. Note: Fewer lines will be output\n");
+ printf(" if Stack limit reached.\n");
}
int main(int argc, char **argv)
{
int ch;
int ret;
- static const char *sopts = "fs:hak:SCn:";
+ static const char *sopts = "fs:hak:SCn:b:l:";
static const struct option lopts[] = {
{"stack-trace", 0, NULL, 'S'},
{"symbol-table", 1, NULL, 's'},
{"frame-pointers", 0, NULL, 'f'},
{"kernel-start", 1, NULL, 'k'},
{"display-stack-pages", 0, NULL, 'n'},
+ {"bytes-per-line", 1, NULL, 'b'},
+ {"lines", 1, NULL, 'l'},
{"all", 0, NULL, 'a'},
{"all-vcpus", 0, NULL, 'C'},
{"help", 0, NULL, 'h'},
@@ -862,6 +889,9 @@ int main(int argc, char **argv)
int vcpu = 0;
+ xenctx.bytes_per_line = DEFAULT_BYTES_PER_LINE;
+ xenctx.lines = DEFAULT_LINES;
+
while ((ch = getopt_long(argc, argv, sopts, lopts, NULL)) != -1) {
switch(ch) {
case 'f':
@@ -879,6 +909,31 @@ int main(int argc, char **argv)
case 'n':
xenctx.multiple_pages = strtol(optarg, NULL, 0);
break;
+ case 'b':
+ xenctx.bytes_per_line = strtol(optarg, NULL, 0);
+ if ( xenctx.bytes_per_line < 4 ||
+ xenctx.bytes_per_line > MAX_BYTES_PER_LINE )
+ {
+ fprintf(stderr,
+ "%s: Unsupported value for --bytes-per-line. Needs to be 4 <= <bytes> <= %d\n",
+ argv[0], MAX_BYTES_PER_LINE);
+ exit(-1);
+ }
+ break;
+ case 'l':
+ if ( !strcmp(optarg, "all") || !strcmp(optarg, "ALL") ||
+ !strcmp(optarg, "max") || !strcmp(optarg, "MAX") )
+ xenctx.lines = INT_MAX;
+ else
+ xenctx.lines = strtol(optarg, NULL, 0);
+ if ( xenctx.lines < 0 )
+ {
+ fprintf(stderr,
+ "%s: Unsupported value for --lines. Needs to be >= 0\n",
+ argv[0]);
+ exit(-1);
+ }
+ break;
case 'C':
xenctx.all_vcpus = 1;
break;
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v5 04/17] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines)
2014-03-20 19:06 ` [PATCH v5 04/17] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines) Don Slutz
@ 2014-03-21 14:32 ` Ian Campbell
2014-03-22 20:08 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 14:32 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, Stefano Stabellini, Ian Jackson, Jan Beulich, xen-devel
On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
> -b <bytes>, --bytes-per-line <bytes>
> change the number of bytes per line output for Stack.
> (default 32) Note: rounded to native size (4 or 8 bytes).
I can just about see a use for this.
> -l <lines>, --lines <lines>
> change the number of lines output for Stack. (default 5)
> Can be specified as MAX. Note: Fewer lines will be output
> if Stack limit reached.
What is this useful for which "less", "head" or "tail" can't achieve?
In both cases though it seems to make the code more complicated for what
seems to be a not all that useful increase in functionality.
> Signed-off-by: Don Slutz <dslutz@verizon.com>
> ---
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH v5 04/17] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines)
2014-03-21 14:32 ` Ian Campbell
@ 2014-03-22 20:08 ` Don Slutz
2014-03-22 20:10 ` Don Slutz
2014-03-24 10:44 ` Ian Campbell
0 siblings, 2 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-22 20:08 UTC (permalink / raw)
To: Ian Campbell
Cc: Stefano Stabellini, George Dunlap, Ian Jackson, Don Slutz,
xen-devel, Jan Beulich
On 03/21/14 10:32, Ian Campbell wrote:
> On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
>> -b <bytes>, --bytes-per-line <bytes>
>> change the number of bytes per line output for Stack.
>> (default 32) Note: rounded to native size (4 or 8 bytes).
> I can just about see a use for this.
This is much more useful when used with --decode-as-ascii or when you
have a wide "terminal".
>> -l <lines>, --lines <lines>
>> change the number of lines output for Stack. (default 5)
>> Can be specified as MAX. Note: Fewer lines will be output
>> if Stack limit reached.
> What is this useful for which "less", "head" or "tail" can't achieve?
By default only part of the stack is dumped:
tools/xentrace/xenctx -s ~/zzm 4 -n 2
rip: ffffffff81346876 io_serial_in+0x16
flags: 00000002 nz
rsp: ffff8800385a5ab8
rax: 000000000000006f rcx: 0000000000000000 rdx: 00000000000003fd
rbx: ffffffff81ff8f00 rsi: 0000000000000005 rdi: ffffffff81ff8f00
rbp: ffff8800385a5ab8 r8: ffffffff81c03a10 r9: 0000000000000080
r10: 0000000000000005 r11: 0000000000000046 r12: 000000000000270f
r13: 0000000000000020 r14: 0000000000000025 r15: ffffffff81346f20
cs: 0010 ss: 0018 ds: 0000 es: 0000
fs: 0000 @ 00007f07972f3700
gs: 0000 @ ffff88000b400000/0000000000000000/
Code (instr addr ffffffff81346876)
48 89 e5 0f 1f 44 00 00 0f b6 4f 41 0f b7 57 08 d3 e6 01 f2 ec <0f> b6
c0 c9 c3 0f 1f 44 00 00 55
Stack:
ffff8800385a5ae8 ffffffff81346e64 ffffffff81ff8f00 0000000000000072
0000000000000064 0000000000000025 ffff8800385a5b08 ffffffff81346f46
ffffffff81e3e430 ffffffff81ff8f00 ffff8800385a5b48 ffffffff813428de
ffffffff8100bc0e 0000000000000000 ffffffff81ff8f00 0000000000000001
0000000000000064 ffffffff81e3e40c ffff8800385a5b98 ffffffff813472ad
Call Trace:
[<ffffffff81346876>] io_serial_in+0x16 <--
[<ffffffff81346e64>] wait_for_xmitr+0x24
[<ffffffff81346f46>] serial8250_console_putchar+0x26
[<ffffffff813428de>] uart_console_write+0x3e
[<ffffffff8100bc0e>] apic_timer_interrupt+0xe
[<ffffffff813472ad>] serial8250_console_write+0xbd
[<ffffffff8106b8f5>] __call_console_drivers+0x75
[<ffffffff8106b95a>] _call_console_drivers+0x4a
[<ffffffff8106be6e>] release_console_sem+0x4e
[<ffffffff8106c628>] vprintk+0x248
[<ffffffff814fd363>] printk+0x41
Here is the same data with a bigger -l (domU is paused):
tools/xentrace/xenctx -s ~/zzm 4 -n 2 -l 10
rip: ffffffff81346876 io_serial_in+0x16
flags: 00000002 nz
rsp: ffff8800385a5ab8
rax: 000000000000006f rcx: 0000000000000000 rdx: 00000000000003fd
rbx: ffffffff81ff8f00 rsi: 0000000000000005 rdi: ffffffff81ff8f00
rbp: ffff8800385a5ab8 r8: ffffffff81c03a10 r9: 0000000000000080
r10: 0000000000000005 r11: 0000000000000046 r12: 000000000000270f
r13: 0000000000000020 r14: 0000000000000025 r15: ffffffff81346f20
cs: 0010 ss: 0018 ds: 0000 es: 0000
fs: 0000 @ 00007f07972f3700
gs: 0000 @ ffff88000b400000/0000000000000000/
Code (instr addr ffffffff81346876)
48 89 e5 0f 1f 44 00 00 0f b6 4f 41 0f b7 57 08 d3 e6 01 f2 ec <0f> b6
c0 c9 c3 0f 1f 44 00 00 55
Stack:
ffff8800385a5ae8 ffffffff81346e64 ffffffff81ff8f00 0000000000000072
0000000000000064 0000000000000025 ffff8800385a5b08 ffffffff81346f46
ffffffff81e3e430 ffffffff81ff8f00 ffff8800385a5b48 ffffffff813428de
ffffffff8100bc0e 0000000000000000 ffffffff81ff8f00 0000000000000001
0000000000000064 ffffffff81e3e40c ffff8800385a5b98 ffffffff813472ad
00000000385a5cd8 0000000000000006 ffff8800385a5c08 ffffffff81affa00
ffffffff81c03800 000000000001696c 0000000000000064 0000000000000046
ffff8800385a5bc8 ffffffff8106b8f5 00000000000169d0 ffffffff81e2797c
00000000000169d0 00000000000169d0 ffff8800385a5be8 ffffffff8106b95a
206465697272616d 00000000fffff167 ffff8800385a5c28 ffffffff8106be6e
Call Trace:
[<ffffffff81346876>] io_serial_in+0x16 <--
[<ffffffff81346e64>] wait_for_xmitr+0x24
[<ffffffff81346f46>] serial8250_console_putchar+0x26
[<ffffffff813428de>] uart_console_write+0x3e
[<ffffffff8100bc0e>] apic_timer_interrupt+0xe
[<ffffffff813472ad>] serial8250_console_write+0xbd
[<ffffffff8106b8f5>] __call_console_drivers+0x75
[<ffffffff8106b95a>] _call_console_drivers+0x4a
[<ffffffff8106be6e>] release_console_sem+0x4e
[<ffffffff8106c628>] vprintk+0x248
[<ffffffff814fd363>] printk+0x41
"less", "head" or "tail" are unable to change xenctx, only control what you see of xenctx's output.
>
> In both cases though it seems to make the code more complicated for what
> seems to be a not all that useful increase in functionality.
It is true that using the existing -S:
tools/xentrace/xenctx -s ~/zzm 4 -S
rip: ffffffff81346876 io_serial_in+0x16
flags: 00000002 nz
rsp: ffff8800385a5ab8
rax: 000000000000006f rcx: 0000000000000000 rdx: 00000000000003fd
rbx: ffffffff81ff8f00 rsi: 0000000000000005 rdi: ffffffff81ff8f00
rbp: ffff8800385a5ab8 r8: ffffffff81c03a10 r9: 0000000000000080
r10: 0000000000000005 r11: 0000000000000046 r12: 000000000000270f
r13: 0000000000000020 r14: 0000000000000025 r15: ffffffff81346f20
cs: 0010 ss: 0018 ds: 0000 es: 0000
fs: 0000 @ 00007f07972f3700
gs: 0000 @ ffff88000b400000/0000000000000000/
Code (instr addr ffffffff81346876)
48 89 e5 0f 1f 44 00 00 0f b6 4f 41 0f b7 57 08 d3 e6 01 f2 ec <0f> b6
c0 c9 c3 0f 1f 44 00 00 55
Stack:
ffff8800385a5ae8 ffffffff81346e64 ffffffff81ff8f00 0000000000000072
0000000000000064 0000000000000025 ffff8800385a5b08 ffffffff81346f46
ffffffff81e3e430 ffffffff81ff8f00 ffff8800385a5b48 ffffffff813428de
ffffffff8100bc0e 0000000000000000 ffffffff81ff8f00 0000000000000001
0000000000000064 ffffffff81e3e40c ffff8800385a5b98 ffffffff813472ad
Stack Trace:
* [<ffffffff81346876>] io_serial_in+0x16 <--
ffff8800385a5ae8
[<ffffffff81346e64>] wait_for_xmitr+0x24
ffffffff81ff8f00
0000000000000072
0000000000000064
0000000000000025
ffff8800385a5b08
[<ffffffff81346f46>] serial8250_console_putchar+0x26
ffffffff81e3e430
ffffffff81ff8f00
ffff8800385a5b48
[<ffffffff813428de>] uart_console_write+0x3e
[<ffffffff8100bc0e>] apic_timer_interrupt+0xe
0000000000000000
ffffffff81ff8f00
0000000000000001
0000000000000064
ffffffff81e3e40c
ffff8800385a5b98
[<ffffffff813472ad>] serial8250_console_write+0xbd
00000000385a5cd8
0000000000000006
ffff8800385a5c08
ffffffff81affa00
ffffffff81c03800
000000000001696c
0000000000000064
0000000000000046
ffff8800385a5bc8
[<ffffffff8106b8f5>] __call_console_drivers+0x75
00000000000169d0
ffffffff81e2797c
00000000000169d0
00000000000169d0
ffff8800385a5be8
[<ffffffff8106b95a>] _call_console_drivers+0x4a
206465697272616d
00000000fffff167
ffff8800385a5c28
[<ffffffff8106be6e>] release_console_sem+0x4e
ffff8800385a5c18
ffff8800385a5c6d
ffffffff81ea7b24
0000000000000064
ffff8800385a5c58
0000000000000034
ffff8800385a5cc8
[<ffffffff8106c628>] vprintk+0x248
ffff8800385a5c98
0000000000000246
7420666f00000000
ffff8800385a5ca8
ffff8800385a5c68
343931206e692072
7365727065722035
ffff8800385a5ca8
0000000000002710
0000000000002710
ffffffff81c03a10
00000000d863e02e
ffff8800385a5d28
ffff8800385a5d38
000000000000003b
00000000021b9010
00007f07972b1010
0000000000000003
ffff8800385a5d28
[<ffffffff814fd363>] printk+0x41
6874202c00000010
ffff8800385a5d38
ffff8800385a5cf8
656e696863616d20
616820796c6e6f20
ffff8800385a5d38
0000000000002710
0000000000002710
ffffffff81c03a10
0000000000000080
ffff8800385a5db8
ffffffffa00a919d
696261706163206e
6977202c7974696c
20612074756f6874
206c6172746e6563
742079726f6d656d
2065726f7473206f
736d6172676f7270
74616420646e6120
754a206e49202e61
2c3534393120656e
6f76206e686f4a20
6e616d75654e206e
000000007570206e
00000000d863e02e
ffff8800385a5dc8
000000000000003a
ffff8800385a5e48
ffffffffa00a91e8
2064656873696c62
2072657061702061
64656c7469746e65
2074737269462720
666f207466617264
726f706572206120
656874206f742074
2c27434156444520
6820657265687720
6e696c74756f2065
6565726874206465
6320636973616220
000000006f706d6f
00000000d863e02e
ffff8800385a5e58
0000000000000039
ffff8800385a5ed8
ffffffffa00a91e8
6f662073746e656e
726f747320612072
72676f72702d6465
75706d6f63206d61
293128203a726574
726f6d656d206120
6961746e6f632079
746f6220676e696e
6120617461642068
7274736e6920646e
3b736e6f69746375
6320612029322820
0000000075636c61
00000000d863e02e
ffff8800385a5ee8
0000000000000038
ffff8800385a5f68
ffffffffa00a91e8
7520676e6974616c
617061632074696e
7020666f20656c62
6e696d726f667265
612068746f622067
6974656d68746972
6f6c20646e612063
706f206c61636967
736e6f6974617265
20656874206e6f20
6e61202c61746164
2061202933282064
00000000746e6f63
00000000d863e02e
ffff8800385a5f78
0000000000000037
ffff8800385a5ff8
ffffffffa00a91e8
74696e75206c6f72
65746e69206f7420
6e69207465727072
6f69746375727473
65726f747320736e
6d656d206e692064
20646e612079726f
63656e20656b616d
6120797261737365
202e736e6f697463
2073692073696854
63206f7320656874
00000000656c6c61
00000000d863e02e
ffff8800385a6008
0000000000000036
ffff8800385a6088
And other tools, you can reformat this output into what -l gives.
It is not that each change makes a big difference, that happens when
several are used at one time:
tools/xentrace/xenctx -s ~/zzm 4 -l 200 -D -t -b 64
rip: ffffffff81346876 io_serial_in+0x16
flags: 00000002 nz
rsp: ffff8800385a5ab8
rax: 000000000000006f rcx: 0000000000000000 rdx: 00000000000003fd
rbx: ffffffff81ff8f00 rsi: 0000000000000005 rdi: ffffffff81ff8f00
rbp: ffff8800385a5ab8 r8: ffffffff81c03a10 r9: 0000000000000080
r10: 0000000000000005 r11: 0000000000000046 r12: 000000000000270f
r13: 0000000000000020 r14: 0000000000000025 r15: ffffffff81346f20
cs: 0010 ss: 0018 ds: 0000 es: 0000
fs: 0000 @ 00007f07972f3700
gs: 0000 @ ffff88000b400000/0000000000000000/
Code (instr addr ffffffff81346876)
48 89 e5 0f 1f 44 00 00 0f b6 4f 41 0f b7 57 08 d3 e6 01 f2 ec <0f> b6
c0 c9 c3 0f 1f 44 00 00 55
Stack:
ffff8800385a5ab8: ffff8800385a5ae8 ffffffff81346e64 ffffffff81ff8f00
0000000000000072 0000000000000064 0000000000000025 ffff8800385a5b08
ffffffff81346f46
.ZZ8....dn4.............r.......d.......%........[Z8....Fo4.....
ffff8800385a5af8: ffffffff81e3e430 ffffffff81ff8f00 ffff8800385a5b48
ffffffff813428de ffffffff8100bc0e 0000000000000000 ffffffff81ff8f00
0000000000000001
0...............H[Z8.....(4.....................................
ffff8800385a5b38: 0000000000000064 ffffffff81e3e40c ffff8800385a5b98
ffffffff813472ad 00000000385a5cd8 0000000000000006 ffff8800385a5c08
ffffffff81affa00
d................[Z8.....r4......\Z8.............\Z8............
ffff8800385a5b78: ffffffff81c03800 000000000001696c 0000000000000064
0000000000000046 ffff8800385a5bc8 ffffffff8106b8f5 00000000000169d0
ffffffff81e2797c
.8......li......d.......F........[Z8.............i......|y......
ffff8800385a5bb8: 00000000000169d0 00000000000169d0 ffff8800385a5be8
ffffffff8106b95a 206465697272616d 00000000fffff167 ffff8800385a5c28
ffffffff8106be6e .i.......i.......[Z8....Z.......married
g.......(\Z8....n.......
ffff8800385a5bf8: ffff8800385a5c18 ffff8800385a5c6d ffffffff81ea7b24
0000000000000064 ffff8800385a5c58 0000000000000034 ffff8800385a5cc8
ffffffff8106c628
.\Z8....m\Z8....${......d.......X\Z8....4........\Z8....(.......
ffff8800385a5c38: ffff8800385a5c98 0000000000000246 7420666f00000000
ffff8800385a5ca8 ffff8800385a5c68 343931206e692072 7365727065722035
ffff8800385a5ca8 .\Z8....F...........of t.\Z8....h\Z8....r in 1945
repres.\Z8....
ffff8800385a5c78: 0000000000002710 0000000000002710 ffffffff81c03a10
00000000d863e02e ffff8800385a5d28 ffff8800385a5d38 000000000000003b
00000000021b9010
.'.......'.......:........c.....(]Z8....8]Z8....;...............
ffff8800385a5cb8: 00007f07972b1010 0000000000000003 ffff8800385a5d28
ffffffff814fd363 6874202c00000010 ffff8800385a5d38 ffff8800385a5cf8
656e696863616d20 ..+.............(]Z8....c.O.........,
th8]Z8.....\Z8.... machine
ffff8800385a5cf8: 616820796c6e6f20 ffff8800385a5d38 0000000000002710
0000000000002710 ffffffff81c03a10 0000000000000080 ffff8800385a5db8
ffffffffa00a919d only
ha8]Z8.....'.......'.......:...............]Z8............
ffff8800385a5d38: 696261706163206e 6977202c7974696c 20612074756f6874
206c6172746e6563 742079726f6d656d 2065726f7473206f 736d6172676f7270
74616420646e6120 n capability, without a central memory to store
programs and dat
ffff8800385a5d78: 754a206e49202e61 2c3534393120656e 6f76206e686f4a20
6e616d75654e206e 000000007570206e 00000000d863e02e ffff8800385a5dc8
000000000000003a a. In June 1945, John von Neumann
pu......c......]Z8....:.......
ffff8800385a5db8: ffff8800385a5e48 ffffffffa00a91e8 2064656873696c62
2072657061702061 64656c7469746e65 2074737269462720 666f207466617264
726f706572206120 H^Z8............blished a paper entitled 'First draft
of a repor
ffff8800385a5df8: 656874206f742074 2c27434156444520 6820657265687720
6e696c74756f2065 6565726874206465 6320636973616220 000000006f706d6f
00000000d863e02e t to the EDVAC', where he outlined three basic
compo......c.....
ffff8800385a5e38: ffff8800385a5e58 0000000000000039 ffff8800385a5ed8
ffffffffa00a91e8 6f662073746e656e 726f747320612072 72676f72702d6465
75706d6f63206d61 X^Z8....9........^Z8............nents for a
stored-program compu
ffff8800385a5e78: 293128203a726574 726f6d656d206120 6961746e6f632079
746f6220676e696e 6120617461642068 7274736e6920646e 3b736e6f69746375
6320612029322820 ter: (1) a memory containing both data and
instructions; (2) a c
ffff8800385a5eb8: 0000000075636c61 00000000d863e02e ffff8800385a5ee8
0000000000000038 ffff8800385a5f68 ffffffffa00a91e8 7520676e6974616c
617061632074696e alcu......c......^Z8....8.......h_Z8............lating
unit capa
ffff8800385a5ef8: 7020666f20656c62 6e696d726f667265 612068746f622067
6974656d68746972 6f6c20646e612063 706f206c61636967 736e6f6974617265
20656874206e6f20 ble of performing both arithmetic and logical
operations on the
ffff8800385a5f38: 6e61202c61746164 2061202933282064 00000000746e6f63
00000000d863e02e ffff8800385a5f78 0000000000000037 ffff8800385a5ff8
ffffffffa00a91e8 data, and (3) a
cont......c.....x_Z8....7........_Z8............
ffff8800385a5f78: 74696e75206c6f72 65746e69206f7420 6e69207465727072
6f69746375727473 65726f747320736e 6d656d206e692064 20646e612079726f
63656e20656b616d rol unit to interpret instructions stored in memory
and make nec
ffff8800385a5fb8: 6120797261737365 202e736e6f697463 2073692073696854
63206f7320656874 00000000656c6c61 00000000d863e02e ffff8800385a6008
0000000000000036 essary actions. This is the so
calle......c......`Z8....6.......
ffff8800385a5ff8: ffff8800385a6088 .`Z8....
Call Trace:
[<ffffffff81346876>] io_serial_in+0x16 <--
[<ffffffff81346e64>] wait_for_xmitr+0x24
[<ffffffff81346f46>] serial8250_console_putchar+0x26
[<ffffffff813428de>] uart_console_write+0x3e
[<ffffffff8100bc0e>] apic_timer_interrupt+0xe
[<ffffffff813472ad>] serial8250_console_write+0xbd
[<ffffffff8106b8f5>] __call_console_drivers+0x75
[<ffffffff8106b95a>] _call_console_drivers+0x4a
[<ffffffff8106be6e>] release_console_sem+0x4e
[<ffffffff8106c628>] vprintk+0x248
[<ffffffff814fd363>] printk+0x41
-Don Slutz
>> Signed-off-by: Don Slutz <dslutz@verizon.com>
>> ---
> Ian.
>
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 04/17] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines)
2014-03-22 20:08 ` Don Slutz
@ 2014-03-22 20:10 ` Don Slutz
2014-03-24 10:44 ` Ian Campbell
1 sibling, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-22 20:10 UTC (permalink / raw)
To: Don Slutz
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Ian Jackson,
xen-devel, Jan Beulich
Grrr. Line wrapping strikes again.
-Don Slutz
On 03/22/14 16:08, Don Slutz wrote:
>
> On 03/21/14 10:32, Ian Campbell wrote:
>> On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
>>> -b <bytes>, --bytes-per-line <bytes>
>>> change the number of bytes per line output for
>>> Stack.
>>> (default 32) Note: rounded to native size (4
>>> or 8 bytes).
>> I can just about see a use for this.
>
> This is much more useful when used with --decode-as-ascii or when you
> have a wide "terminal".
>
>>> -l <lines>, --lines <lines>
>>> change the number of lines output for Stack.
>>> (default 5)
>>> Can be specified as MAX. Note: Fewer lines
>>> will be output
>>> if Stack limit reached.
>> What is this useful for which "less", "head" or "tail" can't achieve?
>
> By default only part of the stack is dumped:
>
>
>
> tools/xentrace/xenctx -s ~/zzm 4 -n 2
> rip: ffffffff81346876 io_serial_in+0x16
> flags: 00000002 nz
> rsp: ffff8800385a5ab8
> rax: 000000000000006f rcx: 0000000000000000 rdx: 00000000000003fd
> rbx: ffffffff81ff8f00 rsi: 0000000000000005 rdi: ffffffff81ff8f00
> rbp: ffff8800385a5ab8 r8: ffffffff81c03a10 r9: 0000000000000080
> r10: 0000000000000005 r11: 0000000000000046 r12: 000000000000270f
> r13: 0000000000000020 r14: 0000000000000025 r15: ffffffff81346f20
> cs: 0010 ss: 0018 ds: 0000 es: 0000
> fs: 0000 @ 00007f07972f3700
> gs: 0000 @ ffff88000b400000/0000000000000000/
> Code (instr addr ffffffff81346876)
> 48 89 e5 0f 1f 44 00 00 0f b6 4f 41 0f b7 57 08 d3 e6 01 f2 ec <0f> b6
> c0 c9 c3 0f 1f 44 00 00 55
>
>
> Stack:
> ffff8800385a5ae8 ffffffff81346e64 ffffffff81ff8f00 0000000000000072
> 0000000000000064 0000000000000025 ffff8800385a5b08 ffffffff81346f46
> ffffffff81e3e430 ffffffff81ff8f00 ffff8800385a5b48 ffffffff813428de
> ffffffff8100bc0e 0000000000000000 ffffffff81ff8f00 0000000000000001
> 0000000000000064 ffffffff81e3e40c ffff8800385a5b98 ffffffff813472ad
>
> Call Trace:
> [<ffffffff81346876>] io_serial_in+0x16 <--
> [<ffffffff81346e64>] wait_for_xmitr+0x24
> [<ffffffff81346f46>] serial8250_console_putchar+0x26
> [<ffffffff813428de>] uart_console_write+0x3e
> [<ffffffff8100bc0e>] apic_timer_interrupt+0xe
> [<ffffffff813472ad>] serial8250_console_write+0xbd
> [<ffffffff8106b8f5>] __call_console_drivers+0x75
> [<ffffffff8106b95a>] _call_console_drivers+0x4a
> [<ffffffff8106be6e>] release_console_sem+0x4e
> [<ffffffff8106c628>] vprintk+0x248
> [<ffffffff814fd363>] printk+0x41
>
>
> Here is the same data with a bigger -l (domU is paused):
>
> tools/xentrace/xenctx -s ~/zzm 4 -n 2 -l 10
> rip: ffffffff81346876 io_serial_in+0x16
> flags: 00000002 nz
> rsp: ffff8800385a5ab8
> rax: 000000000000006f rcx: 0000000000000000 rdx: 00000000000003fd
> rbx: ffffffff81ff8f00 rsi: 0000000000000005 rdi: ffffffff81ff8f00
> rbp: ffff8800385a5ab8 r8: ffffffff81c03a10 r9: 0000000000000080
> r10: 0000000000000005 r11: 0000000000000046 r12: 000000000000270f
> r13: 0000000000000020 r14: 0000000000000025 r15: ffffffff81346f20
> cs: 0010 ss: 0018 ds: 0000 es: 0000
> fs: 0000 @ 00007f07972f3700
> gs: 0000 @ ffff88000b400000/0000000000000000/
> Code (instr addr ffffffff81346876)
> 48 89 e5 0f 1f 44 00 00 0f b6 4f 41 0f b7 57 08 d3 e6 01 f2 ec <0f> b6
> c0 c9 c3 0f 1f 44 00 00 55
>
>
> Stack:
> ffff8800385a5ae8 ffffffff81346e64 ffffffff81ff8f00 0000000000000072
> 0000000000000064 0000000000000025 ffff8800385a5b08 ffffffff81346f46
> ffffffff81e3e430 ffffffff81ff8f00 ffff8800385a5b48 ffffffff813428de
> ffffffff8100bc0e 0000000000000000 ffffffff81ff8f00 0000000000000001
> 0000000000000064 ffffffff81e3e40c ffff8800385a5b98 ffffffff813472ad
> 00000000385a5cd8 0000000000000006 ffff8800385a5c08 ffffffff81affa00
> ffffffff81c03800 000000000001696c 0000000000000064 0000000000000046
> ffff8800385a5bc8 ffffffff8106b8f5 00000000000169d0 ffffffff81e2797c
> 00000000000169d0 00000000000169d0 ffff8800385a5be8 ffffffff8106b95a
> 206465697272616d 00000000fffff167 ffff8800385a5c28 ffffffff8106be6e
>
> Call Trace:
> [<ffffffff81346876>] io_serial_in+0x16 <--
> [<ffffffff81346e64>] wait_for_xmitr+0x24
> [<ffffffff81346f46>] serial8250_console_putchar+0x26
> [<ffffffff813428de>] uart_console_write+0x3e
> [<ffffffff8100bc0e>] apic_timer_interrupt+0xe
> [<ffffffff813472ad>] serial8250_console_write+0xbd
> [<ffffffff8106b8f5>] __call_console_drivers+0x75
> [<ffffffff8106b95a>] _call_console_drivers+0x4a
> [<ffffffff8106be6e>] release_console_sem+0x4e
> [<ffffffff8106c628>] vprintk+0x248
> [<ffffffff814fd363>] printk+0x41
>
>
> "less", "head" or "tail" are unable to change xenctx, only control
> what you see of xenctx's output.
>
>
>
>>
>> In both cases though it seems to make the code more complicated for what
>> seems to be a not all that useful increase in functionality.
>
> It is true that using the existing -S:
>
> tools/xentrace/xenctx -s ~/zzm 4 -S
> rip: ffffffff81346876 io_serial_in+0x16
> flags: 00000002 nz
> rsp: ffff8800385a5ab8
> rax: 000000000000006f rcx: 0000000000000000 rdx: 00000000000003fd
> rbx: ffffffff81ff8f00 rsi: 0000000000000005 rdi: ffffffff81ff8f00
> rbp: ffff8800385a5ab8 r8: ffffffff81c03a10 r9: 0000000000000080
> r10: 0000000000000005 r11: 0000000000000046 r12: 000000000000270f
> r13: 0000000000000020 r14: 0000000000000025 r15: ffffffff81346f20
> cs: 0010 ss: 0018 ds: 0000 es: 0000
> fs: 0000 @ 00007f07972f3700
> gs: 0000 @ ffff88000b400000/0000000000000000/
> Code (instr addr ffffffff81346876)
> 48 89 e5 0f 1f 44 00 00 0f b6 4f 41 0f b7 57 08 d3 e6 01 f2 ec <0f> b6
> c0 c9 c3 0f 1f 44 00 00 55
>
>
> Stack:
> ffff8800385a5ae8 ffffffff81346e64 ffffffff81ff8f00 0000000000000072
> 0000000000000064 0000000000000025 ffff8800385a5b08 ffffffff81346f46
> ffffffff81e3e430 ffffffff81ff8f00 ffff8800385a5b48 ffffffff813428de
> ffffffff8100bc0e 0000000000000000 ffffffff81ff8f00 0000000000000001
> 0000000000000064 ffffffff81e3e40c ffff8800385a5b98 ffffffff813472ad
>
> Stack Trace:
> * [<ffffffff81346876>] io_serial_in+0x16 <--
> ffff8800385a5ae8
> [<ffffffff81346e64>] wait_for_xmitr+0x24
> ffffffff81ff8f00
> 0000000000000072
> 0000000000000064
> 0000000000000025
> ffff8800385a5b08
> [<ffffffff81346f46>] serial8250_console_putchar+0x26
> ffffffff81e3e430
> ffffffff81ff8f00
> ffff8800385a5b48
> [<ffffffff813428de>] uart_console_write+0x3e
> [<ffffffff8100bc0e>] apic_timer_interrupt+0xe
> 0000000000000000
> ffffffff81ff8f00
> 0000000000000001
> 0000000000000064
> ffffffff81e3e40c
> ffff8800385a5b98
> [<ffffffff813472ad>] serial8250_console_write+0xbd
> 00000000385a5cd8
> 0000000000000006
> ffff8800385a5c08
> ffffffff81affa00
> ffffffff81c03800
> 000000000001696c
> 0000000000000064
> 0000000000000046
> ffff8800385a5bc8
> [<ffffffff8106b8f5>] __call_console_drivers+0x75
> 00000000000169d0
> ffffffff81e2797c
> 00000000000169d0
> 00000000000169d0
> ffff8800385a5be8
> [<ffffffff8106b95a>] _call_console_drivers+0x4a
> 206465697272616d
> 00000000fffff167
> ffff8800385a5c28
> [<ffffffff8106be6e>] release_console_sem+0x4e
> ffff8800385a5c18
> ffff8800385a5c6d
> ffffffff81ea7b24
> 0000000000000064
> ffff8800385a5c58
> 0000000000000034
> ffff8800385a5cc8
> [<ffffffff8106c628>] vprintk+0x248
> ffff8800385a5c98
> 0000000000000246
> 7420666f00000000
> ffff8800385a5ca8
> ffff8800385a5c68
> 343931206e692072
> 7365727065722035
> ffff8800385a5ca8
> 0000000000002710
> 0000000000002710
> ffffffff81c03a10
> 00000000d863e02e
> ffff8800385a5d28
> ffff8800385a5d38
> 000000000000003b
> 00000000021b9010
> 00007f07972b1010
> 0000000000000003
> ffff8800385a5d28
> [<ffffffff814fd363>] printk+0x41
> 6874202c00000010
> ffff8800385a5d38
> ffff8800385a5cf8
> 656e696863616d20
> 616820796c6e6f20
> ffff8800385a5d38
> 0000000000002710
> 0000000000002710
> ffffffff81c03a10
> 0000000000000080
> ffff8800385a5db8
> ffffffffa00a919d
> 696261706163206e
> 6977202c7974696c
> 20612074756f6874
> 206c6172746e6563
> 742079726f6d656d
> 2065726f7473206f
> 736d6172676f7270
> 74616420646e6120
> 754a206e49202e61
> 2c3534393120656e
> 6f76206e686f4a20
> 6e616d75654e206e
> 000000007570206e
> 00000000d863e02e
> ffff8800385a5dc8
> 000000000000003a
> ffff8800385a5e48
> ffffffffa00a91e8
> 2064656873696c62
> 2072657061702061
> 64656c7469746e65
> 2074737269462720
> 666f207466617264
> 726f706572206120
> 656874206f742074
> 2c27434156444520
> 6820657265687720
> 6e696c74756f2065
> 6565726874206465
> 6320636973616220
> 000000006f706d6f
> 00000000d863e02e
> ffff8800385a5e58
> 0000000000000039
> ffff8800385a5ed8
> ffffffffa00a91e8
> 6f662073746e656e
> 726f747320612072
> 72676f72702d6465
> 75706d6f63206d61
> 293128203a726574
> 726f6d656d206120
> 6961746e6f632079
> 746f6220676e696e
> 6120617461642068
> 7274736e6920646e
> 3b736e6f69746375
> 6320612029322820
> 0000000075636c61
> 00000000d863e02e
> ffff8800385a5ee8
> 0000000000000038
> ffff8800385a5f68
> ffffffffa00a91e8
> 7520676e6974616c
> 617061632074696e
> 7020666f20656c62
> 6e696d726f667265
> 612068746f622067
> 6974656d68746972
> 6f6c20646e612063
> 706f206c61636967
> 736e6f6974617265
> 20656874206e6f20
> 6e61202c61746164
> 2061202933282064
> 00000000746e6f63
> 00000000d863e02e
> ffff8800385a5f78
> 0000000000000037
> ffff8800385a5ff8
> ffffffffa00a91e8
> 74696e75206c6f72
> 65746e69206f7420
> 6e69207465727072
> 6f69746375727473
> 65726f747320736e
> 6d656d206e692064
> 20646e612079726f
> 63656e20656b616d
> 6120797261737365
> 202e736e6f697463
> 2073692073696854
> 63206f7320656874
> 00000000656c6c61
> 00000000d863e02e
> ffff8800385a6008
> 0000000000000036
> ffff8800385a6088
>
>
> And other tools, you can reformat this output into what -l gives.
>
>
> It is not that each change makes a big difference, that happens when
> several are used at one time:
>
>
> tools/xentrace/xenctx -s ~/zzm 4 -l 200 -D -t -b 64
> rip: ffffffff81346876 io_serial_in+0x16
> flags: 00000002 nz
> rsp: ffff8800385a5ab8
> rax: 000000000000006f rcx: 0000000000000000 rdx: 00000000000003fd
> rbx: ffffffff81ff8f00 rsi: 0000000000000005 rdi: ffffffff81ff8f00
> rbp: ffff8800385a5ab8 r8: ffffffff81c03a10 r9: 0000000000000080
> r10: 0000000000000005 r11: 0000000000000046 r12: 000000000000270f
> r13: 0000000000000020 r14: 0000000000000025 r15: ffffffff81346f20
> cs: 0010 ss: 0018 ds: 0000 es: 0000
> fs: 0000 @ 00007f07972f3700
> gs: 0000 @ ffff88000b400000/0000000000000000/
> Code (instr addr ffffffff81346876)
> 48 89 e5 0f 1f 44 00 00 0f b6 4f 41 0f b7 57 08 d3 e6 01 f2 ec <0f> b6
> c0 c9 c3 0f 1f 44 00 00 55
>
>
> Stack:
> ffff8800385a5ab8: ffff8800385a5ae8 ffffffff81346e64 ffffffff81ff8f00
> 0000000000000072 0000000000000064 0000000000000025 ffff8800385a5b08
> ffffffff81346f46
> .ZZ8....dn4.............r.......d.......%........[Z8....Fo4.....
> ffff8800385a5af8: ffffffff81e3e430 ffffffff81ff8f00 ffff8800385a5b48
> ffffffff813428de ffffffff8100bc0e 0000000000000000 ffffffff81ff8f00
> 0000000000000001
> 0...............H[Z8.....(4.....................................
> ffff8800385a5b38: 0000000000000064 ffffffff81e3e40c ffff8800385a5b98
> ffffffff813472ad 00000000385a5cd8 0000000000000006 ffff8800385a5c08
> ffffffff81affa00
> d................[Z8.....r4......\Z8.............\Z8............
> ffff8800385a5b78: ffffffff81c03800 000000000001696c 0000000000000064
> 0000000000000046 ffff8800385a5bc8 ffffffff8106b8f5 00000000000169d0
> ffffffff81e2797c
> .8......li......d.......F........[Z8.............i......|y......
> ffff8800385a5bb8: 00000000000169d0 00000000000169d0 ffff8800385a5be8
> ffffffff8106b95a 206465697272616d 00000000fffff167 ffff8800385a5c28
> ffffffff8106be6e .i.......i.......[Z8....Z.......married
> g.......(\Z8....n.......
> ffff8800385a5bf8: ffff8800385a5c18 ffff8800385a5c6d ffffffff81ea7b24
> 0000000000000064 ffff8800385a5c58 0000000000000034 ffff8800385a5cc8
> ffffffff8106c628
> .\Z8....m\Z8....${......d.......X\Z8....4........\Z8....(.......
> ffff8800385a5c38: ffff8800385a5c98 0000000000000246 7420666f00000000
> ffff8800385a5ca8 ffff8800385a5c68 343931206e692072 7365727065722035
> ffff8800385a5ca8 .\Z8....F...........of t.\Z8....h\Z8....r in 1945
> repres.\Z8....
> ffff8800385a5c78: 0000000000002710 0000000000002710 ffffffff81c03a10
> 00000000d863e02e ffff8800385a5d28 ffff8800385a5d38 000000000000003b
> 00000000021b9010
> .'.......'.......:........c.....(]Z8....8]Z8....;...............
> ffff8800385a5cb8: 00007f07972b1010 0000000000000003 ffff8800385a5d28
> ffffffff814fd363 6874202c00000010 ffff8800385a5d38 ffff8800385a5cf8
> 656e696863616d20 ..+.............(]Z8....c.O.........,
> th8]Z8.....\Z8.... machine
> ffff8800385a5cf8: 616820796c6e6f20 ffff8800385a5d38 0000000000002710
> 0000000000002710 ffffffff81c03a10 0000000000000080 ffff8800385a5db8
> ffffffffa00a919d only
> ha8]Z8.....'.......'.......:...............]Z8............
> ffff8800385a5d38: 696261706163206e 6977202c7974696c 20612074756f6874
> 206c6172746e6563 742079726f6d656d 2065726f7473206f 736d6172676f7270
> 74616420646e6120 n capability, without a central memory to store
> programs and dat
> ffff8800385a5d78: 754a206e49202e61 2c3534393120656e 6f76206e686f4a20
> 6e616d75654e206e 000000007570206e 00000000d863e02e ffff8800385a5dc8
> 000000000000003a a. In June 1945, John von Neumann
> pu......c......]Z8....:.......
> ffff8800385a5db8: ffff8800385a5e48 ffffffffa00a91e8 2064656873696c62
> 2072657061702061 64656c7469746e65 2074737269462720 666f207466617264
> 726f706572206120 H^Z8............blished a paper entitled 'First draft
> of a repor
> ffff8800385a5df8: 656874206f742074 2c27434156444520 6820657265687720
> 6e696c74756f2065 6565726874206465 6320636973616220 000000006f706d6f
> 00000000d863e02e t to the EDVAC', where he outlined three basic
> compo......c.....
> ffff8800385a5e38: ffff8800385a5e58 0000000000000039 ffff8800385a5ed8
> ffffffffa00a91e8 6f662073746e656e 726f747320612072 72676f72702d6465
> 75706d6f63206d61 X^Z8....9........^Z8............nents for a
> stored-program compu
> ffff8800385a5e78: 293128203a726574 726f6d656d206120 6961746e6f632079
> 746f6220676e696e 6120617461642068 7274736e6920646e 3b736e6f69746375
> 6320612029322820 ter: (1) a memory containing both data and
> instructions; (2) a c
> ffff8800385a5eb8: 0000000075636c61 00000000d863e02e ffff8800385a5ee8
> 0000000000000038 ffff8800385a5f68 ffffffffa00a91e8 7520676e6974616c
> 617061632074696e
> alcu......c......^Z8....8.......h_Z8............lating unit capa
> ffff8800385a5ef8: 7020666f20656c62 6e696d726f667265 612068746f622067
> 6974656d68746972 6f6c20646e612063 706f206c61636967 736e6f6974617265
> 20656874206e6f20 ble of performing both arithmetic and logical
> operations on the
> ffff8800385a5f38: 6e61202c61746164 2061202933282064 00000000746e6f63
> 00000000d863e02e ffff8800385a5f78 0000000000000037 ffff8800385a5ff8
> ffffffffa00a91e8 data, and (3) a
> cont......c.....x_Z8....7........_Z8............
> ffff8800385a5f78: 74696e75206c6f72 65746e69206f7420 6e69207465727072
> 6f69746375727473 65726f747320736e 6d656d206e692064 20646e612079726f
> 63656e20656b616d rol unit to interpret instructions stored in memory
> and make nec
> ffff8800385a5fb8: 6120797261737365 202e736e6f697463 2073692073696854
> 63206f7320656874 00000000656c6c61 00000000d863e02e ffff8800385a6008
> 0000000000000036 essary actions. This is the so
> calle......c......`Z8....6.......
> ffff8800385a5ff8: ffff8800385a6088 .`Z8....
>
> Call Trace:
> [<ffffffff81346876>] io_serial_in+0x16 <--
> [<ffffffff81346e64>] wait_for_xmitr+0x24
> [<ffffffff81346f46>] serial8250_console_putchar+0x26
> [<ffffffff813428de>] uart_console_write+0x3e
> [<ffffffff8100bc0e>] apic_timer_interrupt+0xe
> [<ffffffff813472ad>] serial8250_console_write+0xbd
> [<ffffffff8106b8f5>] __call_console_drivers+0x75
> [<ffffffff8106b95a>] _call_console_drivers+0x4a
> [<ffffffff8106be6e>] release_console_sem+0x4e
> [<ffffffff8106c628>] vprintk+0x248
> [<ffffffff814fd363>] printk+0x41
>
>
> -Don Slutz
>
>>> Signed-off-by: Don Slutz <dslutz@verizon.com>
>>> ---
>> Ian.
>>
>
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 04/17] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines)
2014-03-22 20:08 ` Don Slutz
2014-03-22 20:10 ` Don Slutz
@ 2014-03-24 10:44 ` Ian Campbell
2014-03-24 16:58 ` Don Slutz
1 sibling, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-24 10:44 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, Stefano Stabellini, Ian Jackson, Jan Beulich, xen-devel
On Sat, 2014-03-22 at 16:08 -0400, Don Slutz wrote:
> On 03/21/14 10:32, Ian Campbell wrote:
> By default only part of the stack is dumped:
Why not dump the whole page by default then? 5 lines seems rather
arbitrary.
> "less", "head" or "tail" are unable to change xenctx, only control
> what you see of xenctx's output.
Obviously! I'm not sure what your point is though -- my suggestion was
that xenctx should/could output stuff which can be processed with these
tools.
> It is not that each change makes a big difference, that happens when
> several are used at one time:
Can we not just improve the default behaviour to be more useful? Having
to give half a dozen different options to get useful output isn't really
all that user friendly.
I accept that some options might have to remain in order to work sanely
on 80-column displays but we should aim in the first instance to have
the tool Do The Right/Useful Thing without needing extra options.
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH v5 04/17] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines)
2014-03-24 10:44 ` Ian Campbell
@ 2014-03-24 16:58 ` Don Slutz
2014-03-27 15:55 ` Ian Campbell
0 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-24 16:58 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: George Dunlap, Stefano Stabellini, Ian Jackson, Jan Beulich, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 2409 bytes --]
On 03/24/14 06:44, Ian Campbell wrote:
> On Sat, 2014-03-22 at 16:08 -0400, Don Slutz wrote:
>> On 03/21/14 10:32, Ian Campbell wrote:
>> By default only part of the stack is dumped:
> Why not dump the whole page by default then? 5 lines seems rather
> arbitrary.
5 is what it use to be. Not sure how much the default in linux is.
I have no issue with changing the default to MAX. However I got
from reading Jan Beulich comments in Nov 2013, that these changes
should not be intrusive.
>> "less", "head" or "tail" are unable to change xenctx, only control
>> what you see of xenctx's output.
> Obviously! I'm not sure what your point is though -- my suggestion was
> that xenctx should/could output stuff which can be processed with these
> tools.
Looks like I misunderstood you.
>> It is not that each change makes a big difference, that happens when
>> several are used at one time:
> Can we not just improve the default behaviour to be more useful? Having
> to give half a dozen different options to get useful output isn't really
> all that user friendly.
These are directly in response to:
-------- Original Message --------
Subject: Re: [PATCH v2 04/12] xenctx: Add stack address to dump, switch to 16 bytes per line.
Date: Thu, 7 Nov 2013 08:12:44 +0000
From: Jan Beulich <JBeulich@suse.com>
To: Don Slutz <dslutz@verizon.com>
CC: Ian Campbell <ian.campbell@citrix.com>, Don Slutz <Don@CloudSwitch.com>, George Dunlap <george.dunlap@eu.citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, xen-devel <xen-devel@lists.xenproject.org>
>>> On 06.11.13 at 21:08, Don Slutz <dslutz@verizon.com> wrote:
Again - why? This makes it just two entries per line for a 64-bit
guest. Pretty little I would say.
Jan
> I accept that some options might have to remain in order to work sanely
> on 80-column displays but we should aim in the first instance to have
> the tool Do The Right/Useful Thing without needing extra options.
I am currently not sure that "Do The Right/Useful Thing" is the same
for all the people involved.
Are you asking for some kind of config file that allows a developer to select
their preferred setting of options, or just to determine the best defaults?
Last I knew Jan Beulich does not what -t and you and I do. The issue is that
-t by default pushes the output to > 80 columns.
-Don Slutz
> Ian.
>
[-- Attachment #1.2: Type: text/html, Size: 5414 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 04/17] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines)
2014-03-24 16:58 ` Don Slutz
@ 2014-03-27 15:55 ` Ian Campbell
2014-03-27 19:36 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-27 15:55 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, Stefano Stabellini, Ian Jackson, Jan Beulich, xen-devel
On Mon, 2014-03-24 at 12:58 -0400, Don Slutz wrote:
> On 03/24/14 06:44, Ian Campbell wrote:
>
> > On Sat, 2014-03-22 at 16:08 -0400, Don Slutz wrote:
> > > On 03/21/14 10:32, Ian Campbell wrote:
> > > By default only part of the stack is dumped:
> > Why not dump the whole page by default then? 5 lines seems rather
> > arbitrary.
>
> 5 is what it use to be. Not sure how much the default in linux is.
>
> I have no issue with changing the default to MAX. However I got
> from reading Jan Beulich comments in Nov 2013, that these changes
> should not be intrusive.
I think we are way past intrusive...
> > > It is not that each change makes a big difference, that happens when
> > > several are used at one time:
> > Can we not just improve the default behaviour to be more useful? Having
> > to give half a dozen different options to get useful output isn't really
> > all that user friendly.
>
> These are directly in response to:
Please can you get out of the habit of just cutting and pasting emails
in response to questions, it's very hard to make sense of what you are
trying to say when you do this. Just answer the question directly.
AFAICT the answer to my question is that a previous attempt at this
change you changed the default behaviour and this was questioned because
it reduced the amount of information on a line to a non-useful amount.
Is that right? Did you agree with that assessment from Jan? If so then
the right answer to my question would have been:
I tried this, but it resulted in only two stack entries per line
which Jan pointed out wasn't very many so I decided to make it
an option.
If you didn't agree with Jan then did you make a counter argument?
> > I accept that some options might have to remain in order to work sanely
> > on 80-column displays but we should aim in the first instance to have
> > the tool Do The Right/Useful Thing without needing extra options.
>
> I am currently not sure that "Do The Right/Useful Thing" is the same
> for all the people involved.
It's not a hard and fast rule ("I accept that some options might have to
remain"). What I am saying is please think about improving the defaults
where it makes sense to do so. If you decide that adding a new option is
the right thing to do then
> Are you asking for some kind of config file that allows a developer to
> select their preferred setting of options,
Oh god no.
> or just to determine the best defaults?
Yes, at least where possible.
> Last I knew Jan Beulich does not what -t and you and I do. The issue
> is that
> -t by default pushes the output to > 80 columns.
I don't want things over 80 columns either.
I want to know that you have thought about the tradeoffs of adding a new
option and concluded that a new option is better than changing the
defaults -- the obvious way to stop me questioning this sort of thing
would be to explain the choice in the commit message in the first place.
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 04/17] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines)
2014-03-27 15:55 ` Ian Campbell
@ 2014-03-27 19:36 ` Don Slutz
0 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-27 19:36 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: George Dunlap, xen-devel, Ian Jackson, Jan Beulich, Stefano Stabellini
On 03/27/14 11:55, Ian Campbell wrote:
> On Mon, 2014-03-24 at 12:58 -0400, Don Slutz wrote:
>> On 03/24/14 06:44, Ian Campbell wrote:
> I think we are way past intrusive...
>
Source code yes. Output before v8 by default no.
The v8 drop of -T is the 1st visible change from just running it.
> Please can you get out of the habit of just cutting and pasting emails
> in response to questions, it's very hard to make sense of what you are
> trying to say when you do this. Just answer the question directly.
Still adjusting to the right level. Sorry about the cost to you.
[...]
> I don't want things over 80 columns either.
>
> I want to know that you have thought about the tradeoffs of adding a new
> option and concluded that a new option is better than changing the
> defaults -- the obvious way to stop me questioning this sort of thing
> would be to explain the choice in the commit message in the first place.
Good to know. I hope the commit message changes in v8 help.
-Don Slutz
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH v5 05/17] xenctx: Add command line option -D (--decode-as-ascii)
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (3 preceding siblings ...)
2014-03-20 19:06 ` [PATCH v5 04/17] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines) Don Slutz
@ 2014-03-20 19:06 ` Don Slutz
2014-03-21 14:38 ` Ian Campbell
2014-03-20 19:06 ` [PATCH v5 06/17] xenctx: Add command line option -t (--tag-stack-dump) Don Slutz
` (12 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:06 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Don Slutz,
Ian Jackson, Don Slutz, Jan Beulich
If specified, output ascii version of stack also.
Here is an example:
Stack:
ffffffff80048d19 0000000000200800 ffffffff803e7801 0000000000086800 .......... ......x>......h......
0000000000000000 ffffffff80430720 ffffffff803e722f 80008e000010019c ........ .C...../r>.............
00000000ffffffff 0000000000000000 0000000000000000 0000000000200000 .......................... .....
0000000000000000 0000000000000000 ................
Signed-off-by: Don Slutz <Don@CloudSwitch.com>
---
v5: Add comment, move printf.
tools/xentrace/xenctx.c | 39 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index f540b61..f4a5125 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -42,6 +42,7 @@ static struct xenctx {
int multiple_pages;
int bytes_per_line;
int lines;
+ int decode_as_ascii;
int all_vcpus;
int self_paused;
xc_dominfo_t dominfo;
@@ -669,6 +670,7 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
guest_word_t frame;
guest_word_t word;
guest_word_t *p;
+ guest_word_t ascii[MAX_BYTES_PER_LINE/4];
int i;
if ( width )
@@ -683,6 +685,9 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
printf("Stack:\n");
for (i = 1; i < xenctx.lines + 1 && stack < stack_limit; i++)
{
+ int j = 0;
+ int k;
+
while ( stack < stack_limit &&
stack < stack_pointer(ctx) + i * xenctx.bytes_per_line )
{
@@ -690,10 +695,36 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
if ( !p )
return -1;
word = read_stack_word(p, width);
+ if ( xenctx.decode_as_ascii )
+ ascii[j++] = word;
printf(" ");
print_stack_word(word, width);
stack += width;
}
+ if ( xenctx.decode_as_ascii )
+ {
+ /*
+ * Line up ascii output if less than bytes_per_line
+ * were printed.
+ */
+ for (k = j; k < xenctx.bytes_per_line / width; k++)
+ printf(" %*s", width * 2, "");
+ printf(" ");
+ for (k = 0; k < j; k++)
+ {
+ int l;
+ unsigned char *bytep = (unsigned char*)&ascii[k];
+
+ for (l = 0; l < width; l++)
+ {
+ if (isprint(*bytep))
+ printf("%c", *bytep);
+ else
+ printf(".");
+ bytep++;
+ }
+ }
+ }
printf("\n");
}
printf("\n");
@@ -865,19 +896,22 @@ static void usage(void)
DEFAULT_LINES);
printf(" Can be specified as MAX. Note: Fewer lines will be output\n");
printf(" if Stack limit reached.\n");
+ printf(" -D, --decode-as-ascii\n");
+ printf(" add a decode of Stack dump as ascii.\n");
}
int main(int argc, char **argv)
{
int ch;
int ret;
- static const char *sopts = "fs:hak:SCn:b:l:";
+ static const char *sopts = "fs:hak:SCn:b:l:D";
static const struct option lopts[] = {
{"stack-trace", 0, NULL, 'S'},
{"symbol-table", 1, NULL, 's'},
{"frame-pointers", 0, NULL, 'f'},
{"kernel-start", 1, NULL, 'k'},
{"display-stack-pages", 0, NULL, 'n'},
+ {"decode-as-ascii", 0, NULL, 'D'},
{"bytes-per-line", 1, NULL, 'b'},
{"lines", 1, NULL, 'l'},
{"all", 0, NULL, 'a'},
@@ -909,6 +943,9 @@ int main(int argc, char **argv)
case 'n':
xenctx.multiple_pages = strtol(optarg, NULL, 0);
break;
+ case 'D':
+ xenctx.decode_as_ascii = 1;
+ break;
case 'b':
xenctx.bytes_per_line = strtol(optarg, NULL, 0);
if ( xenctx.bytes_per_line < 4 ||
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v5 05/17] xenctx: Add command line option -D (--decode-as-ascii)
2014-03-20 19:06 ` [PATCH v5 05/17] xenctx: Add command line option -D (--decode-as-ascii) Don Slutz
@ 2014-03-21 14:38 ` Ian Campbell
2014-03-21 18:42 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 14:38 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
> If specified, output ascii version of stack also.
I suppose this is optional because the result is >100 chars wide?
Otherwise making it unconditional would be a nobrainer.
> printf(" ");
> print_stack_word(word, width);
> stack += width;
> }
> + if ( xenctx.decode_as_ascii )
> + {
> + /*
> + * Line up ascii output if less than bytes_per_line
> + * were printed.
> + */
> + for (k = j; k < xenctx.bytes_per_line / width; k++)
> + printf(" %*s", width * 2, "");
Avoid the loop by using width*2*((xenctx.bytes_per_line / width)-j) ?
(or whatever the sums are)
At some point in the future perhaps
https://plus.google.com/111319147897550904359/posts/cZ6QVUAMAhT
will be widespread enoguh that we can all stop with this sort of
thing...
Ian
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 05/17] xenctx: Add command line option -D (--decode-as-ascii)
2014-03-21 14:38 ` Ian Campbell
@ 2014-03-21 18:42 ` Don Slutz
2014-03-24 10:46 ` Ian Campbell
0 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-21 18:42 UTC (permalink / raw)
To: Ian Campbell
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
Don Slutz, xen-devel, Jan Beulich
On 03/21/14 10:38, Ian Campbell wrote:
> On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
>> If specified, output ascii version of stack also.
> I suppose this is optional because the result is >100 chars wide?
> Otherwise making it unconditional would be a nobrainer.
No not 100, but it does exceed 80 and from a previous email:
-------- Original Message --------
Subject: Re: [PATCH v2 03/12] xenctx: Output ascii version of stack also.
Date: Thu, 7 Nov 2013 12:43:14 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
Organization: Citrix Systems, Inc.
To: Jan Beulich <JBeulich@suse.com>
CC: Don Slutz <dslutz@verizon.com>, Don Slutz <Don@CloudSwitch.com>,
"George Dunlap" <george.dunlap@eu.citrix.com>, Ian Jackson
<ian.jackson@eu.citrix.com>, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>, xen-devel
<xen-devel@lists.xenproject.org>
On Thu, 2013-11-07 at 08:09 +0000, Jan Beulich wrote:
> >>> On 06.11.13 at 21:08, Don Slutz <dslutz@verizon.com> wrote:
>
> Why? I personally don't see a need - there's rarely much useful
> ASCII data on the stack.
This is true IME
> So afaic: If at all, then only via command
> line option defaulting to off.
Well, assuming it doesn't make the output >80 columns (which I can't
tell from here) it seems harmless enough?
...
>
>> printf(" ");
>> print_stack_word(word, width);
>> stack += width;
>> }
>> + if ( xenctx.decode_as_ascii )
>> + {
>> + /*
>> + * Line up ascii output if less than bytes_per_line
>> + * were printed.
>> + */
>> + for (k = j; k < xenctx.bytes_per_line / width; k++)
>> + printf(" %*s", width * 2, "");
> Avoid the loop by using width*2*((xenctx.bytes_per_line / width)-j) ?
> (or whatever the sums are)
I could, but you also need to include the test some how (and as an "if"
is almost the same). And for code that is only ever run a few times in
a developer tool, I do not see that the speed or output "breakage" make
a big difference. But if you really want this...
> At some point in the future perhaps
> https://plus.google.com/111319147897550904359/posts/cZ6QVUAMAhT
> will be widespread enoguh that we can all stop with this sort of
> thing...
Well, I wish them good luck. Getting the right terminal width to happen
100% of the time when going through many remote hops, just does not
happen to me. (local stuff is just so much simpler.)
Also getting a table to look right with variable spacing and variable sized
"characters" is very hard. Last I knew the technical writers
still are hand adjusting things even now.
-Don Slutz
> Ian
>
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 05/17] xenctx: Add command line option -D (--decode-as-ascii)
2014-03-21 18:42 ` Don Slutz
@ 2014-03-24 10:46 ` Ian Campbell
2014-03-24 17:00 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-24 10:46 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Fri, 2014-03-21 at 14:42 -0400, Don Slutz wrote:
> On 03/21/14 10:38, Ian Campbell wrote:
> > On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
> >> If specified, output ascii version of stack also.
> > I suppose this is optional because the result is >100 chars wide?
> > Otherwise making it unconditional would be a nobrainer.
>
> No not 100, but it does exceed 80 and from a previous email:
This having already been queried and explained I would have then
expected the commit message to say something like "This is not the
default because the result exceeds 80 characters per line"
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH v5 05/17] xenctx: Add command line option -D (--decode-as-ascii)
2014-03-24 10:46 ` Ian Campbell
@ 2014-03-24 17:00 ` Don Slutz
0 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-24 17:00 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On 03/24/14 06:46, Ian Campbell wrote:
> On Fri, 2014-03-21 at 14:42 -0400, Don Slutz wrote:
>> On 03/21/14 10:38, Ian Campbell wrote:
>>> On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
>>>> If specified, output ascii version of stack also.
>>> I suppose this is optional because the result is >100 chars wide?
>>> Otherwise making it unconditional would be a nobrainer.
>> No not 100, but it does exceed 80 and from a previous email:
> This having already been queried and explained I would have then
> expected the commit message to say something like "This is not the
> default because the result exceeds 80 characters per line"
Will add to commit message.
-Don Slutz
> Ian.
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH v5 06/17] xenctx: Add command line option -t (--tag-stack-dump)
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (4 preceding siblings ...)
2014-03-20 19:06 ` [PATCH v5 05/17] xenctx: Add command line option -D (--decode-as-ascii) Don Slutz
@ 2014-03-20 19:06 ` Don Slutz
2014-03-21 14:40 ` Ian Campbell
2014-03-20 19:06 ` [PATCH v5 07/17] xenctx: Change print_symbol to do the space before Don Slutz
` (11 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:06 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Don Slutz,
Ian Jackson, Don Slutz, Jan Beulich
If specified, add stack address to dump.
Here is an example:
Stack:
ffffffff803ddf90: ffffffff80048d19 0000000000200800 ffffffff803e7801 0000000000086800
ffffffff803ddfb0: 0000000000000000 ffffffff80430720 ffffffff803e722f 80008e000010019c
ffffffff803ddfd0: 00000000ffffffff 0000000000000000 0000000000000000 0000000000200000
ffffffff803ddff0: 0000000000000000 0000000000000000
Signed-off-by: Don Slutz <Don@CloudSwitch.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
---
tools/xentrace/xenctx.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index f4a5125..93b50af 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -43,6 +43,7 @@ static struct xenctx {
int bytes_per_line;
int lines;
int decode_as_ascii;
+ int tag_stack_dump;
int all_vcpus;
int self_paused;
xc_dominfo_t dominfo;
@@ -688,6 +689,11 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
int j = 0;
int k;
+ if ( xenctx.tag_stack_dump )
+ {
+ print_stack_word(stack, width);
+ printf(":");
+ }
while ( stack < stack_limit &&
stack < stack_pointer(ctx) + i * xenctx.bytes_per_line )
{
@@ -898,13 +904,15 @@ static void usage(void)
printf(" if Stack limit reached.\n");
printf(" -D, --decode-as-ascii\n");
printf(" add a decode of Stack dump as ascii.\n");
+ printf(" -t, --tag-stack-dump\n");
+ printf(" add address on each line of Stack dump.\n");
}
int main(int argc, char **argv)
{
int ch;
int ret;
- static const char *sopts = "fs:hak:SCn:b:l:D";
+ static const char *sopts = "fs:hak:SCn:b:l:Dt";
static const struct option lopts[] = {
{"stack-trace", 0, NULL, 'S'},
{"symbol-table", 1, NULL, 's'},
@@ -912,6 +920,7 @@ int main(int argc, char **argv)
{"kernel-start", 1, NULL, 'k'},
{"display-stack-pages", 0, NULL, 'n'},
{"decode-as-ascii", 0, NULL, 'D'},
+ {"tag-stack-dump", 0, NULL, 't'},
{"bytes-per-line", 1, NULL, 'b'},
{"lines", 1, NULL, 'l'},
{"all", 0, NULL, 'a'},
@@ -946,6 +955,9 @@ int main(int argc, char **argv)
case 'D':
xenctx.decode_as_ascii = 1;
break;
+ case 't':
+ xenctx.tag_stack_dump = 1;
+ break;
case 'b':
xenctx.bytes_per_line = strtol(optarg, NULL, 0);
if ( xenctx.bytes_per_line < 4 ||
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v5 06/17] xenctx: Add command line option -t (--tag-stack-dump)
2014-03-20 19:06 ` [PATCH v5 06/17] xenctx: Add command line option -t (--tag-stack-dump) Don Slutz
@ 2014-03-21 14:40 ` Ian Campbell
0 siblings, 0 replies; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 14:40 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
> If specified, add stack address to dump.
>
> Here is an example:
>
> Stack:
> ffffffff803ddf90: ffffffff80048d19 0000000000200800 ffffffff803e7801 0000000000086800
> ffffffff803ddfb0: 0000000000000000 ffffffff80430720 ffffffff803e722f 80008e000010019c
> ffffffff803ddfd0: 00000000ffffffff 0000000000000000 0000000000000000 0000000000200000
> ffffffff803ddff0: 0000000000000000 0000000000000000
>
> Signed-off-by: Don Slutz <Don@CloudSwitch.com>
> Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH v5 07/17] xenctx: Change print_symbol to do the space before.
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (5 preceding siblings ...)
2014-03-20 19:06 ` [PATCH v5 06/17] xenctx: Add command line option -t (--tag-stack-dump) Don Slutz
@ 2014-03-20 19:06 ` Don Slutz
2014-03-20 19:06 ` [PATCH v5 08/17] xenctx: More info on failed to map page Don Slutz
` (10 subsequent siblings)
17 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:06 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Don Slutz,
Ian Jackson, Jan Beulich
From: Don Slutz <Don@CloudSwitch.com>
This stops the output of an extra space at the end of the line.
Signed-off-by: Don Slutz <Don@CloudSwitch.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
---
tools/xentrace/xenctx.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index 93b50af..d4e8935 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -170,9 +170,9 @@ static void print_symbol(guest_word_t addr)
return;
if (addr==s->address)
- printf("%s ", s->name);
+ printf(" %s", s->name);
else
- printf("%s+%#x ", s->name, (unsigned int)(addr - s->address));
+ printf(" %s+%#x", s->name, (unsigned int)(addr - s->address));
}
static void read_symbol_table(const char *symtab)
@@ -311,7 +311,7 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
{
struct cpu_user_regs_x86_32 *regs = &ctx->user_regs;
- printf("cs:eip: %04x:%08x ", regs->cs, regs->eip);
+ printf("cs:eip: %04x:%08x", regs->cs, regs->eip);
print_symbol(regs->eip);
print_flags(regs->eflags);
printf("ss:esp: %04x:%08x\n", regs->ss, regs->esp);
@@ -340,7 +340,7 @@ static void print_ctx_32on64(vcpu_guest_context_x86_64_t *ctx)
{
struct cpu_user_regs_x86_64 *regs = &ctx->user_regs;
- printf("cs:eip: %04x:%08x ", regs->cs, (uint32_t)regs->eip);
+ printf("cs:eip: %04x:%08x", regs->cs, (uint32_t)regs->eip);
print_symbol((uint32_t)regs->eip);
print_flags((uint32_t)regs->eflags);
printf("ss:esp: %04x:%08x\n", regs->ss, (uint32_t)regs->esp);
@@ -369,7 +369,7 @@ static void print_ctx_64(vcpu_guest_context_x86_64_t *ctx)
{
struct cpu_user_regs_x86_64 *regs = &ctx->user_regs;
- printf("rip: %016"PRIx64" ", regs->rip);
+ printf("rip: %016"PRIx64, regs->rip);
print_symbol(regs->rip);
print_flags(regs->rflags);
printf("rsp: %016"PRIx64"\n", regs->rsp);
@@ -467,7 +467,7 @@ static void print_ctx_32(vcpu_guest_context_t *ctx)
{
vcpu_guest_core_regs_t *regs = &ctx->user_regs;
- printf("PC: %08"PRIx32" ", regs->pc32);
+ printf("PC: %08"PRIx32, regs->pc32);
print_symbol(regs->pc32);
printf("\n");
printf("CPSR: %08"PRIx32"\n", regs->cpsr);
@@ -519,7 +519,7 @@ static void print_ctx_64(vcpu_guest_context_t *ctx)
{
vcpu_guest_core_regs_t *regs = &ctx->user_regs;
- printf("PC: %016"PRIx64" ", regs->pc64);
+ printf("PC: %016"PRIx64, regs->pc64);
print_symbol(regs->pc64);
printf("\n");
@@ -742,7 +742,7 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
printf("Call Trace:\n");
printf("%c [<", xenctx.stack_trace ? '*' : ' ');
print_stack_word(instr_pointer(ctx), width);
- printf(">] ");
+ printf(">]");
print_symbol(instr_pointer(ctx));
printf(" <--\n");
@@ -782,7 +782,7 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
word = read_stack_word(p, width);
printf("%c [<", xenctx.stack_trace ? '|' : ' ');
print_stack_word(word, width);
- printf(">] ");
+ printf(">]");
print_symbol(word);
printf("\n");
stack += width;
@@ -798,7 +798,7 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
if (is_kernel_text(word)) {
printf(" [<");
print_stack_word(word, width);
- printf(">] ");
+ printf(">]");
print_symbol(word);
printf("\n");
} else if (xenctx.stack_trace) {
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* [PATCH v5 08/17] xenctx: More info on failed to map page.
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (6 preceding siblings ...)
2014-03-20 19:06 ` [PATCH v5 07/17] xenctx: Change print_symbol to do the space before Don Slutz
@ 2014-03-20 19:06 ` Don Slutz
2014-03-20 19:06 ` [PATCH v5 09/17] xenctx: Add command line option -T (--tag-trace) Don Slutz
` (9 subsequent siblings)
17 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:06 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Don Slutz,
Ian Jackson, Jan Beulich
From: Don Slutz <Don@CloudSwitch.com>
Also output an extra new line since we may be in the middle of output.
Signed-off-by: Don Slutz <Don@CloudSwitch.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
---
tools/xentrace/xenctx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index d4e8935..107e353 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -617,7 +617,7 @@ static void *map_page(vcpu_guest_context_any_t *ctx, int vcpu, guest_word_t virt
mapped = xc_map_foreign_range(xenctx.xc_handle, xenctx.domid, XC_PAGE_SIZE, PROT_READ, mfn);
if (mapped == NULL) {
- fprintf(stderr, "failed to map page.\n");
+ fprintf(stderr, "\nfailed to map page for "FMT_32B_WORD".\n", virt);
return NULL;
}
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* [PATCH v5 09/17] xenctx: Add command line option -T (--tag-trace)
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (7 preceding siblings ...)
2014-03-20 19:06 ` [PATCH v5 08/17] xenctx: More info on failed to map page Don Slutz
@ 2014-03-20 19:06 ` Don Slutz
2014-03-21 14:44 ` Ian Campbell
2014-03-20 19:06 ` [PATCH v5 10/17] xenctx: Add -m (--memory) <maddr> option to dump memory at maddr Don Slutz
` (8 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:06 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Don Slutz,
Ian Jackson, Don Slutz, Jan Beulich
If specified, add stack addr to Call and Stack trace.
Here is an example:
Call Trace:
[<ffffffff8006b2b0>] default_idle+0x29 <--
ffffffff803ddf90: [<ffffffff80048d19>] cpu_idle+0x95
ffffffff803ddfa0: [<ffffffff803e7801>] start_kernel+0x220
ffffffff803ddfc0: [<ffffffff803e722f>] x86_64_start_kernel+0x22f
and
Stack Trace:
* [<ffffffff8006b2b0>] default_idle+0x29 <--
ffffffff803ddf90: [<ffffffff80048d19>] cpu_idle+0x95
ffffffff803ddf98: 0000000000200800
ffffffff803ddfa0: [<ffffffff803e7801>] start_kernel+0x220
ffffffff803ddfa8: 0000000000086800
ffffffff803ddfb0: 0000000000000000
ffffffff803ddfb8: ffffffff80430720
ffffffff803ddfc0: [<ffffffff803e722f>] x86_64_start_kernel+0x22f
ffffffff803ddfc8: 80008e000010019c
ffffffff803ddfd0: 00000000ffffffff
ffffffff803ddfd8: 0000000000000000
ffffffff803ddfe0: 0000000000000000
ffffffff803ddfe8: 0000000000200000
ffffffff803ddff0: 0000000000000000
ffffffff803ddff8: 0000000000000000
Signed-off-by: Don Slutz <Don@CloudSwitch.com>
---
v5: Adjust option name, usage.
tools/xentrace/xenctx.c | 53 ++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 46 insertions(+), 7 deletions(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index 107e353..5732665 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -44,6 +44,7 @@ static struct xenctx {
int lines;
int decode_as_ascii;
int tag_stack_dump;
+ int tag_call_trace;
int all_vcpus;
int self_paused;
xc_dominfo_t dominfo;
@@ -740,6 +741,8 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
printf("Stack Trace:\n");
else
printf("Call Trace:\n");
+ if ( xenctx.tag_call_trace )
+ printf(" %*s", width*2, "");
printf("%c [<", xenctx.stack_trace ? '*' : ' ');
print_stack_word(instr_pointer(ctx), width);
printf(">]");
@@ -755,9 +758,15 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
p = map_page(ctx, vcpu, stack);
if (!p)
return -1;
- printf("| ");
+ if ( xenctx.tag_call_trace )
+ {
+ print_stack_word(stack, width);
+ printf(": | ");
+ } else {
+ printf("| ");
+ }
print_stack_word(read_stack_word(p, width), width);
- printf(" \n");
+ printf("\n");
stack += width;
}
} else {
@@ -769,7 +778,13 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
return -1;
frame = read_stack_word(p, width);
if (xenctx.stack_trace) {
- printf("|-- ");
+ if ( xenctx.tag_call_trace )
+ {
+ print_stack_word(stack, width);
+ printf(": |-- ");
+ } else {
+ printf("|-- ");
+ }
print_stack_word(read_stack_word(p, width), width);
printf("\n");
}
@@ -780,7 +795,13 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
if (!p)
return -1;
word = read_stack_word(p, width);
- printf("%c [<", xenctx.stack_trace ? '|' : ' ');
+ if ( xenctx.tag_call_trace )
+ {
+ print_stack_word(stack, width);
+ printf(": %c [<", xenctx.stack_trace ? '|' : ' ');
+ } else {
+ printf("%c [<", xenctx.stack_trace ? '|' : ' ');
+ }
print_stack_word(word, width);
printf(">]");
print_symbol(word);
@@ -796,13 +817,25 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
return -1;
word = read_stack_word(p, width);
if (is_kernel_text(word)) {
- printf(" [<");
+ if ( xenctx.tag_call_trace )
+ {
+ print_stack_word(stack, width);
+ printf(": [<");
+ } else {
+ printf(" [<");
+ }
print_stack_word(word, width);
printf(">]");
print_symbol(word);
printf("\n");
} else if (xenctx.stack_trace) {
- printf(" ");
+ if ( xenctx.tag_call_trace )
+ {
+ print_stack_word(stack, width);
+ printf(": ");
+ } else {
+ printf(" ");
+ }
print_stack_word(word, width);
printf("\n");
}
@@ -906,13 +939,15 @@ static void usage(void)
printf(" add a decode of Stack dump as ascii.\n");
printf(" -t, --tag-stack-dump\n");
printf(" add address on each line of Stack dump.\n");
+ printf(" -T, --tag-trace\n");
+ printf(" add address on each line of Call or Stack trace.\n");
}
int main(int argc, char **argv)
{
int ch;
int ret;
- static const char *sopts = "fs:hak:SCn:b:l:Dt";
+ static const char *sopts = "fs:hak:SCn:b:l:DtT";
static const struct option lopts[] = {
{"stack-trace", 0, NULL, 'S'},
{"symbol-table", 1, NULL, 's'},
@@ -921,6 +956,7 @@ int main(int argc, char **argv)
{"display-stack-pages", 0, NULL, 'n'},
{"decode-as-ascii", 0, NULL, 'D'},
{"tag-stack-dump", 0, NULL, 't'},
+ {"tag-trace", 0, NULL, 'T'},
{"bytes-per-line", 1, NULL, 'b'},
{"lines", 1, NULL, 'l'},
{"all", 0, NULL, 'a'},
@@ -958,6 +994,9 @@ int main(int argc, char **argv)
case 't':
xenctx.tag_stack_dump = 1;
break;
+ case 'T':
+ xenctx.tag_call_trace = 1;
+ break;
case 'b':
xenctx.bytes_per_line = strtol(optarg, NULL, 0);
if ( xenctx.bytes_per_line < 4 ||
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v5 09/17] xenctx: Add command line option -T (--tag-trace)
2014-03-20 19:06 ` [PATCH v5 09/17] xenctx: Add command line option -T (--tag-trace) Don Slutz
@ 2014-03-21 14:44 ` Ian Campbell
2014-03-24 19:54 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 14:44 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
> If specified, add stack addr to Call and Stack trace.
This could safely be unconditional I think.
Or if not then it should share an option with --tag-stack-dump, e.g.
-a,--print-addresses
> @@ -755,9 +758,15 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
> p = map_page(ctx, vcpu, stack);
> if (!p)
> return -1;
> - printf("| ");
> + if ( xenctx.tag_call_trace )
> + {
> + print_stack_word(stack, width);
> + printf(": | ");
> + } else {
> + printf("| ");
> + }
if (trace)
print stack work
print ": "
}
print ("| ")
(the examples you gave have no vertical | in them -- are they out of
date?)
> @@ -769,7 +778,13 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
> return -1;
> frame = read_stack_word(p, width);
> if (xenctx.stack_trace) {
> - printf("|-- ");
> + if ( xenctx.tag_call_trace )
> + {
> + print_stack_word(stack, width);
> + printf(": |-- ");
> + } else {
> + printf("|-- ");
> + }
Same comment as above.
> print_stack_word(read_stack_word(p, width), width);
> printf("\n");
> }
> @@ -780,7 +795,13 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
> if (!p)
> return -1;
> word = read_stack_word(p, width);
> - printf("%c [<", xenctx.stack_trace ? '|' : ' ');
> + if ( xenctx.tag_call_trace )
> + {
> + print_stack_word(stack, width);
> + printf(": %c [<", xenctx.stack_trace ? '|' : ' ');
> + } else {
> + printf("%c [<", xenctx.stack_trace ? '|' : ' ');
> + }
and again (here the code duplication is especially intolerable)
> print_stack_word(word, width);
> printf(">]");
> print_symbol(word);
> @@ -796,13 +817,25 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
> return -1;
> word = read_stack_word(p, width);
> if (is_kernel_text(word)) {
> - printf(" [<");
> + if ( xenctx.tag_call_trace )
> + {
> + print_stack_word(stack, width);
> + printf(": [<");
> + } else {
> + printf(" [<");
> + }
again.
> print_stack_word(word, width);
> printf(">]");
> print_symbol(word);
> printf("\n");
> } else if (xenctx.stack_trace) {
> - printf(" ");
> + if ( xenctx.tag_call_trace )
> + {
> + print_stack_word(stack, width);
> + printf(": ");
> + } else {
> + printf(" ");
> + }
again.
It almost like a print_stack_trace helper is in order.
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 09/17] xenctx: Add command line option -T (--tag-trace)
2014-03-21 14:44 ` Ian Campbell
@ 2014-03-24 19:54 ` Don Slutz
2014-03-27 15:56 ` Ian Campbell
0 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-24 19:54 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On 03/21/14 10:44, Ian Campbell wrote:
> On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
>> If specified, add stack addr to Call and Stack trace.
> This could safely be unconditional I think.
>
> Or if not then it should share an option with --tag-stack-dump, e.g.
> -a,--print-addresses
>
Ok.
>> @@ -755,9 +758,15 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
>> p = map_page(ctx, vcpu, stack);
>> if (!p)
>> return -1;
>> - printf("| ");
>> + if ( xenctx.tag_call_trace )
>> + {
>> + print_stack_word(stack, width);
>> + printf(": | ");
>> + } else {
>> + printf("| ");
>> + }
> if (trace)
> print stack work
> print ": "
> }
> print ("| ")
>
> (the examples you gave have no vertical | in them -- are they out of
> date?)
Nope. These are non "-f -S" output.
Here is "-f -S" output:
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 -f -S 2
rip: ffffffff810387db native_safe_halt+0xb
flags: 00000246 i z p
rsp: ffffffff81a03ec8
rax: 0000000000000000 rcx: 0000000000000000 rdx: 0000000000000000
rbx: 0000000000000000 rsi: 0000000000000001 rdi: ffffffff81ddc228
rbp: ffffffff81a03ec8 r8: 0000000000000000 r9: 0000000000000000
r10: 000001f319222f0f r11: ffffffff81a03e68 r12: ffffffff81c03800
r13: 0000000000000000 r14: ffffffffffffffff r15: 000000000008a790
cs: 0010 ss: 0018 ds: 0018 es: 0018
fs: 0000 @ 0000000000000000
gs: 0000 @ ffff88000b400000/0000000000000000/
Code (instr addr ffffffff810387db)
44 00 00 fb c9 c3 0f 1f 40 00 55 48 89 e5 0f 1f 44 00 00 fb f4 <c9> c3 0f 1f 00 55 48 89 e5 0f 1f
Stack:
ffffffff81a03ee8 ffffffff810149cd ffffffff81a03fd8 ffffffff81c03800
ffffffff81a03f18 ffffffff81009e06 6db6db6db6db6db7 e8be668bda5ab5b6
0000000000000000 6db6db6db6db6db7 ffffffff81a03f28 ffffffff814e447a
ffffffff81a03f68 ffffffff81c23f7b 8d0573d9e73df7bb ffffffff81c6b440
0000000002014024 0000000000000000 ffffffff81dd9000 ffffffff81a03fa8
Stack Trace:
* [<ffffffff810387db>] native_safe_halt+0xb <--
|-- ffffffff81a03ee8
| [<ffffffff810149cd>] default_idle+0x4d
| ffffffff81a03fd8
| ffffffff81c03800
|-- ffffffff81a03f18
| [<ffffffff81009e06>] cpu_idle+0xb6
| 6db6db6db6db6db7
| e8be668bda5ab5b6
| 0000000000000000
| 6db6db6db6db6db7
|-- ffffffff81a03f28
| [<ffffffff814e447a>] rest_init+0x7a
|-- ffffffff81a03f68
| [<ffffffff81c23f7b>] start_kernel+0x424
| 8d0573d9e73df7bb
| ffffffff81c6b440
| 0000000002014024
| 0000000000000000
| ffffffff81dd9000
| ffffffff81a03fa8
|-- ffffffff81a03f88
| [<ffffffff81c2333a>] x86_64_start_reservations+0x125
| ffffffff81a03fa8
| 0000000000000020
|-- ffffffff81a03fe8
| [<ffffffff81c23438>] x86_64_start_kernel+0xfa
| 0000000000000000
| 0000000000000000
| 81c28e0000103136
| 00000000ffffffff
| 0000000000000000
| 0000000000000000
| 0000000000000000
| 0000000000000000
| 0000000000000000
| 0000000000000000
|-- 0000000000000000
>> @@ -769,7 +778,13 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
>> return -1;
>> frame = read_stack_word(p, width);
>> if (xenctx.stack_trace) {
>> - printf("|-- ");
>> + if ( xenctx.tag_call_trace )
>> + {
>> + print_stack_word(stack, width);
>> + printf(": |-- ");
>> + } else {
>> + printf("|-- ");
>> + }
> Same comment as above.
>
>> print_stack_word(read_stack_word(p, width), width);
>> printf("\n");
>> }
>> @@ -780,7 +795,13 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
>> if (!p)
>> return -1;
>> word = read_stack_word(p, width);
>> - printf("%c [<", xenctx.stack_trace ? '|' : ' ');
>> + if ( xenctx.tag_call_trace )
>> + {
>> + print_stack_word(stack, width);
>> + printf(": %c [<", xenctx.stack_trace ? '|' : ' ');
>> + } else {
>> + printf("%c [<", xenctx.stack_trace ? '|' : ' ');
>> + }
> and again (here the code duplication is especially intolerable)
>
>> print_stack_word(word, width);
>> printf(">]");
>> print_symbol(word);
>> @@ -796,13 +817,25 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
>> return -1;
>> word = read_stack_word(p, width);
>> if (is_kernel_text(word)) {
>> - printf(" [<");
>> + if ( xenctx.tag_call_trace )
>> + {
>> + print_stack_word(stack, width);
>> + printf(": [<");
>> + } else {
>> + printf(" [<");
>> + }
> again.
>
>> print_stack_word(word, width);
>> printf(">]");
>> print_symbol(word);
>> printf("\n");
>> } else if (xenctx.stack_trace) {
>> - printf(" ");
>> + if ( xenctx.tag_call_trace )
>> + {
>> + print_stack_word(stack, width);
>> + printf(": ");
>> + } else {
>> + printf(" ");
>> + }
> again.
>
> It almost like a print_stack_trace helper is in order.
>
>
Ok, I will recode these all as routine that is basicly:
+ if ( xenctx.tag_call_trace )
+ {
+ print_stack_word(stack, width);
+ printf(": ");
+ }
-Don Slutz
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 09/17] xenctx: Add command line option -T (--tag-trace)
2014-03-24 19:54 ` Don Slutz
@ 2014-03-27 15:56 ` Ian Campbell
0 siblings, 0 replies; 77+ messages in thread
From: Ian Campbell @ 2014-03-27 15:56 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Mon, 2014-03-24 at 15:54 -0400, Don Slutz wrote:
> Nope. These are non "-f -S" output.
Ah, ok.
> > It almost like a print_stack_trace helper is in order.
> >
> >
>
> Ok, I will recode these all as routine that is basicly:
Yes, thanks.
>
>
> + if ( xenctx.tag_call_trace )
> + {
> + print_stack_word(stack, width);
> + printf(": ");
> + }
>
>
>
> -Don Slutz
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH v5 10/17] xenctx: Add -m (--memory) <maddr> option to dump memory at maddr.
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (8 preceding siblings ...)
2014-03-20 19:06 ` [PATCH v5 09/17] xenctx: Add command line option -T (--tag-trace) Don Slutz
@ 2014-03-20 19:06 ` Don Slutz
2014-03-21 14:53 ` Ian Campbell
2014-03-20 19:06 ` [PATCH v5 11/17] xenctx: Add -d (--dump-as-stack) <daddr> option to dump memory at daddr as a stack Don Slutz
` (7 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:06 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Don Slutz,
Ian Jackson, Don Slutz, Jan Beulich
Currently not supported on ARM.
New routine read_mem_word() will correctly read a word that crosses
a page boundary. It will not fault if the 2nd page can not be
mapped.
Here is an example:
Memory (address ffffffff803ddf90):
ffffffff80048d19 0000000000200800 ffffffff803e7801 0000000000086800
0000000000000000 ffffffff80430720 ffffffff803e722f 80008e000010019c
00000000ffffffff 0000000000000000 0000000000000000 0000000000200000
0000000000000000 0000000000000000 0000000000000000 00cf9b000000ffff
00af9b000000ffff 00cf93000000ffff 00cffb000000ffff 00cff3000000ffff
Signed-off-by: Don Slutz <Don@CloudSwitch.com>
---
v5: Remove extra #ifndef. Make common routine print_lines().
tools/xentrace/xenctx.c | 232 +++++++++++++++++++++++++++++++++---------------
1 file changed, 162 insertions(+), 70 deletions(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index 5732665..13f56ed 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -33,23 +33,6 @@
#define DEFAULT_BYTES_PER_LINE 32
#define DEFAULT_LINES 5
-static struct xenctx {
- xc_interface *xc_handle;
- int domid;
- int frame_ptrs;
- int stack_trace;
- int disp_all;
- int multiple_pages;
- int bytes_per_line;
- int lines;
- int decode_as_ascii;
- int tag_stack_dump;
- int tag_call_trace;
- int all_vcpus;
- int self_paused;
- xc_dominfo_t dominfo;
-} xenctx;
-
#if defined (__i386__) || defined (__x86_64__)
typedef unsigned long long guest_word_t;
#define FMT_32B_WORD "%08llx"
@@ -73,6 +56,27 @@ typedef uint64_t guest_word_t;
#define MAX_BYTES_PER_LINE 128
+static struct xenctx {
+ xc_interface *xc_handle;
+ int domid;
+ int frame_ptrs;
+ int stack_trace;
+ int disp_all;
+ int multiple_pages;
+ int bytes_per_line;
+ int lines;
+ int decode_as_ascii;
+ int tag_stack_dump;
+ int tag_call_trace;
+ int all_vcpus;
+#ifndef NO_TRANSLATION
+ guest_word_t mem_addr;
+ int do_memory;
+#endif
+ int self_paused;
+ xc_dominfo_t dominfo;
+} xenctx;
+
struct symbol {
guest_word_t address;
char *name;
@@ -634,6 +638,36 @@ static guest_word_t read_stack_word(guest_word_t *src, int width)
return word;
}
+static guest_word_t read_mem_word(vcpu_guest_context_any_t *ctx, int vcpu,
+ guest_word_t virt, int width)
+{
+ if ( (virt & 7) == 0 )
+ {
+ guest_word_t *p = map_page(ctx, vcpu, virt);
+
+ if ( p )
+ return read_stack_word(p, width);
+ else
+ return -1;
+ } else {
+ guest_word_t word = -1;
+ char *src, *dst;
+ int i;
+
+ dst = (char*)&word;
+ for (i = 0; i < width; i++ )
+ {
+ src = map_page(ctx, vcpu, virt + i);
+ if ( src )
+ *dst++ = *src;
+ else
+ return word;
+ }
+ return word;
+ }
+}
+#endif
+
static void print_stack_word(guest_word_t word, int width)
{
if (width == 4)
@@ -642,6 +676,78 @@ static void print_stack_word(guest_word_t word, int width)
printf(FMT_64B_WORD, word);
}
+#ifndef NO_TRANSLATION
+static int print_lines(vcpu_guest_context_any_t *ctx, int vcpu, int width,
+ guest_word_t mem_addr, guest_word_t mem_limit)
+{
+ guest_word_t mem_start = mem_addr;
+ guest_word_t word;
+ guest_word_t ascii[MAX_BYTES_PER_LINE/4];
+ int i;
+
+ for (i = 1; i < xenctx.lines + 1 && mem_addr < mem_limit; i++)
+ {
+ int j = 0;
+ int k;
+
+ if ( xenctx.tag_stack_dump )
+ {
+ print_stack_word(mem_addr, width);
+ printf(":");
+ }
+ while ( mem_addr < mem_limit &&
+ mem_addr < mem_start + i * xenctx.bytes_per_line )
+ {
+ void *p = map_page(ctx, vcpu, mem_addr);
+ if ( !p )
+ return -1;
+ word = read_mem_word(ctx, vcpu, mem_addr, width);
+ if ( xenctx.decode_as_ascii )
+ ascii[j++] = word;
+ printf(" ");
+ print_stack_word(word, width);
+ mem_addr += width;
+ }
+ if ( xenctx.decode_as_ascii )
+ {
+ /*
+ * Line up ascii output if less than bytes_per_line
+ * were printed.
+ */
+ for (k = j; k < xenctx.bytes_per_line / width; k++)
+ printf(" %*s", width * 2, "");
+ printf(" ");
+ for (k = 0; k < j; k++)
+ {
+ int l;
+ unsigned char *bytep = (unsigned char*)&ascii[k];
+
+ for (l = 0; l < width; l++)
+ {
+ if (isprint(*bytep))
+ printf("%c", *bytep);
+ else
+ printf(".");
+ bytep++;
+ }
+ }
+ }
+ printf("\n");
+ }
+ printf("\n");
+ return 0;
+}
+
+static void print_mem(vcpu_guest_context_any_t *ctx, int vcpu, int width,
+ guest_word_t mem_addr)
+{
+ printf("Memory (address ");
+ print_stack_word(mem_addr, width);
+ printf("):\n");
+ print_lines(ctx, vcpu, width, mem_addr,
+ mem_addr + xenctx.lines * xenctx.bytes_per_line);
+}
+
static int print_code(vcpu_guest_context_any_t *ctx, int vcpu)
{
guest_word_t instr;
@@ -672,8 +778,6 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
guest_word_t frame;
guest_word_t word;
guest_word_t *p;
- guest_word_t ascii[MAX_BYTES_PER_LINE/4];
- int i;
if ( width )
xenctx.bytes_per_line = ((xenctx.bytes_per_line + width - 1) / width) * width;
@@ -685,56 +789,8 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
if ( xenctx.lines )
{
printf("Stack:\n");
- for (i = 1; i < xenctx.lines + 1 && stack < stack_limit; i++)
- {
- int j = 0;
- int k;
-
- if ( xenctx.tag_stack_dump )
- {
- print_stack_word(stack, width);
- printf(":");
- }
- while ( stack < stack_limit &&
- stack < stack_pointer(ctx) + i * xenctx.bytes_per_line )
- {
- p = map_page(ctx, vcpu, stack);
- if ( !p )
- return -1;
- word = read_stack_word(p, width);
- if ( xenctx.decode_as_ascii )
- ascii[j++] = word;
- printf(" ");
- print_stack_word(word, width);
- stack += width;
- }
- if ( xenctx.decode_as_ascii )
- {
- /*
- * Line up ascii output if less than bytes_per_line
- * were printed.
- */
- for (k = j; k < xenctx.bytes_per_line / width; k++)
- printf(" %*s", width * 2, "");
- printf(" ");
- for (k = 0; k < j; k++)
- {
- int l;
- unsigned char *bytep = (unsigned char*)&ascii[k];
-
- for (l = 0; l < width; l++)
- {
- if (isprint(*bytep))
- printf("%c", *bytep);
- else
- printf(".");
- bytep++;
- }
- }
- }
- printf("\n");
- }
- printf("\n");
+ if ( print_lines(ctx, vcpu, width, stack, stack_limit) )
+ return -1;
}
if(xenctx.stack_trace)
@@ -882,6 +938,13 @@ static void dump_ctx(int vcpu)
}
#endif
+#ifndef NO_TRANSLATION
+ if ( xenctx.do_memory )
+ {
+ print_mem(&ctx, vcpu, guest_word_size, xenctx.mem_addr);
+ return;
+ }
+#endif
print_ctx(&ctx);
#ifndef NO_TRANSLATION
if (print_code(&ctx, vcpu))
@@ -941,13 +1004,21 @@ static void usage(void)
printf(" add address on each line of Stack dump.\n");
printf(" -T, --tag-trace\n");
printf(" add address on each line of Call or Stack trace.\n");
+#ifndef NO_TRANSLATION
+ printf(" -m maddr, --memory=maddr\n");
+ printf(" dump memory at maddr.\n");
+#endif
}
int main(int argc, char **argv)
{
int ch;
int ret;
+#ifndef NO_TRANSLATION
+ static const char *sopts = "fs:hak:SCn:b:l:DtTm:";
+#else
static const char *sopts = "fs:hak:SCn:b:l:DtT";
+#endif
static const struct option lopts[] = {
{"stack-trace", 0, NULL, 'S'},
{"symbol-table", 1, NULL, 's'},
@@ -957,6 +1028,9 @@ int main(int argc, char **argv)
{"decode-as-ascii", 0, NULL, 'D'},
{"tag-stack-dump", 0, NULL, 't'},
{"tag-trace", 0, NULL, 'T'},
+#ifndef NO_TRANSLATION
+ {"memory", 1, NULL, 'm'},
+#endif
{"bytes-per-line", 1, NULL, 'b'},
{"lines", 1, NULL, 'l'},
{"all", 0, NULL, 'a'},
@@ -967,6 +1041,7 @@ int main(int argc, char **argv)
const char *symbol_table = NULL;
int vcpu = 0;
+ int do_default = 1;
xenctx.bytes_per_line = DEFAULT_BYTES_PER_LINE;
xenctx.lines = DEFAULT_LINES;
@@ -1024,10 +1099,18 @@ int main(int argc, char **argv)
break;
case 'C':
xenctx.all_vcpus = 1;
+ do_default = 0;
break;
case 'k':
kernel_start = strtoull(optarg, NULL, 0);
break;
+#ifndef NO_TRANSLATION
+ case 'm':
+ xenctx.mem_addr = strtoull(optarg, NULL, 0);
+ xenctx.do_memory = 1;
+ do_default = 0;
+ break;
+#endif
case 'h':
usage();
exit(-1);
@@ -1077,9 +1160,18 @@ int main(int argc, char **argv)
xenctx.self_paused = 1;
}
+#ifndef NO_TRANSLATION
+ if ( xenctx.do_memory )
+ {
+ dump_ctx(vcpu);
+ if (xenctx.all_vcpus)
+ printf("\n");
+ }
+ xenctx.do_memory = 0;
+#endif
if (xenctx.all_vcpus)
dump_all_vcpus();
- else
+ if ( do_default )
dump_ctx(vcpu);
if (xenctx.self_paused) {
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v5 10/17] xenctx: Add -m (--memory) <maddr> option to dump memory at maddr.
2014-03-20 19:06 ` [PATCH v5 10/17] xenctx: Add -m (--memory) <maddr> option to dump memory at maddr Don Slutz
@ 2014-03-21 14:53 ` Ian Campbell
2014-03-25 19:16 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 14:53 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
> Currently not supported on ARM.
>
> New routine read_mem_word() will correctly read a word that crosses
> a page boundary. It will not fault if the 2nd page can not be
> mapped.
>
> Here is an example:
> Memory (address ffffffff803ddf90):
> ffffffff80048d19 0000000000200800 ffffffff803e7801 0000000000086800
> 0000000000000000 ffffffff80430720 ffffffff803e722f 80008e000010019c
> 00000000ffffffff 0000000000000000 0000000000000000 0000000000200000
> 0000000000000000 0000000000000000 0000000000000000 00cf9b000000ffff
> 00af9b000000ffff 00cf93000000ffff 00cffb000000ffff 00cff3000000ffff
>
> Signed-off-by: Don Slutz <Don@CloudSwitch.com>
> ---
> v5: Remove extra #ifndef. Make common routine print_lines().
>
> tools/xentrace/xenctx.c | 232 +++++++++++++++++++++++++++++++++---------------
> 1 file changed, 162 insertions(+), 70 deletions(-)
>
> diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
> index 5732665..13f56ed 100644
> --- a/tools/xentrace/xenctx.c
> +++ b/tools/xentrace/xenctx.c
> @@ -33,23 +33,6 @@
> #define DEFAULT_BYTES_PER_LINE 32
> #define DEFAULT_LINES 5
>
> -static struct xenctx {
> - xc_interface *xc_handle;
> - int domid;
> - int frame_ptrs;
> - int stack_trace;
> - int disp_all;
> - int multiple_pages;
> - int bytes_per_line;
> - int lines;
> - int decode_as_ascii;
> - int tag_stack_dump;
> - int tag_call_trace;
> - int all_vcpus;
> - int self_paused;
> - xc_dominfo_t dominfo;
> -} xenctx;
> -
> #if defined (__i386__) || defined (__x86_64__)
> typedef unsigned long long guest_word_t;
> #define FMT_32B_WORD "%08llx"
> @@ -73,6 +56,27 @@ typedef uint64_t guest_word_t;
>
> #define MAX_BYTES_PER_LINE 128
>
> +static struct xenctx {
> + xc_interface *xc_handle;
> + int domid;
> + int frame_ptrs;
> + int stack_trace;
> + int disp_all;
> + int multiple_pages;
> + int bytes_per_line;
> + int lines;
> + int decode_as_ascii;
> + int tag_stack_dump;
> + int tag_call_trace;
> + int all_vcpus;
> +#ifndef NO_TRANSLATION
> + guest_word_t mem_addr;
> + int do_memory;
> +#endif
> + int self_paused;
> + xc_dominfo_t dominfo;
> +} xenctx;
> +
This motion seems to be unmotivated by the commit message.
(I've no idea why there is a struct for this stuff anyway, even though
there is a good chance I added it, it could just as easily be globals in
a program of this sort)
> int main(int argc, char **argv)
> {
> int ch;
> int ret;
> +#ifndef NO_TRANSLATION
> + static const char *sopts = "fs:hak:SCn:b:l:DtTm:";
> +#else
> static const char *sopts = "fs:hak:SCn:b:l:DtT";
> +#endif
static const char *sopts = "fs:hak:SCn:b:l:DtT"
#ifdef ....
"m:"
#endif
;
Or something to avoid that massive repetition. Another possibility:
#ifndef NO_TRANSLATION
#define TRANSLATION_OPTS "m:"
#else
#define TRANSLATION_OPTS
#endif
sopts = "fs:....." TRANS...._OPTS
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 10/17] xenctx: Add -m (--memory) <maddr> option to dump memory at maddr.
2014-03-21 14:53 ` Ian Campbell
@ 2014-03-25 19:16 ` Don Slutz
0 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-25 19:16 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On 03/21/14 10:53, Ian Campbell wrote:
> On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
>> Currently not supported on ARM.
>>
>> New routine read_mem_word() will correctly read a word that crosses
>> a page boundary. It will not fault if the 2nd page can not be
>> mapped.
>>
>> Here is an example:
>> Memory (address ffffffff803ddf90):
>> ffffffff80048d19 0000000000200800 ffffffff803e7801 0000000000086800
>> 0000000000000000 ffffffff80430720 ffffffff803e722f 80008e000010019c
>> 00000000ffffffff 0000000000000000 0000000000000000 0000000000200000
>> 0000000000000000 0000000000000000 0000000000000000 00cf9b000000ffff
>> 00af9b000000ffff 00cf93000000ffff 00cffb000000ffff 00cff3000000ffff
>>
>> Signed-off-by: Don Slutz <Don@CloudSwitch.com>
>> ---
>> v5: Remove extra #ifndef. Make common routine print_lines().
>>
>> tools/xentrace/xenctx.c | 232 +++++++++++++++++++++++++++++++++---------------
>> 1 file changed, 162 insertions(+), 70 deletions(-)
>>
>> diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
>> index 5732665..13f56ed 100644
>> --- a/tools/xentrace/xenctx.c
>> +++ b/tools/xentrace/xenctx.c
>> @@ -33,23 +33,6 @@
>> #define DEFAULT_BYTES_PER_LINE 32
>> #define DEFAULT_LINES 5
>>
>> -static struct xenctx {
>> - xc_interface *xc_handle;
>> - int domid;
>> - int frame_ptrs;
>> - int stack_trace;
>> - int disp_all;
>> - int multiple_pages;
>> - int bytes_per_line;
>> - int lines;
>> - int decode_as_ascii;
>> - int tag_stack_dump;
>> - int tag_call_trace;
>> - int all_vcpus;
>> - int self_paused;
>> - xc_dominfo_t dominfo;
>> -} xenctx;
>> -
>> #if defined (__i386__) || defined (__x86_64__)
>> typedef unsigned long long guest_word_t;
>> #define FMT_32B_WORD "%08llx"
>> @@ -73,6 +56,27 @@ typedef uint64_t guest_word_t;
>>
>> #define MAX_BYTES_PER_LINE 128
>>
>> +static struct xenctx {
>> + xc_interface *xc_handle;
>> + int domid;
>> + int frame_ptrs;
>> + int stack_trace;
>> + int disp_all;
>> + int multiple_pages;
>> + int bytes_per_line;
>> + int lines;
>> + int decode_as_ascii;
>> + int tag_stack_dump;
>> + int tag_call_trace;
>> + int all_vcpus;
>> +#ifndef NO_TRANSLATION
>> + guest_word_t mem_addr;
>> + int do_memory;
>> +#endif
>> + int self_paused;
>> + xc_dominfo_t dominfo;
>> +} xenctx;
>> +
> This motion seems to be unmotivated by the commit message.
I will add the reason to the commit message:
Moved xenctx because guest_word_t is not defined where it was.
> (I've no idea why there is a struct for this stuff anyway, even though
> there is a good chance I added it, it could just as easily be globals in
> a program of this sort)
I just went with what was there...
>> int main(int argc, char **argv)
>> {
>> int ch;
>> int ret;
>> +#ifndef NO_TRANSLATION
>> + static const char *sopts = "fs:hak:SCn:b:l:DtTm:";
>> +#else
>> static const char *sopts = "fs:hak:SCn:b:l:DtT";
>> +#endif
> static const char *sopts = "fs:hak:SCn:b:l:DtT"
> #ifdef ....
> "m:"
> #endif
> ;
This is the way it use to be:
#ifdef __ia64__
"r:"
#endif
>
> Or something to avoid that massive repetition. Another possibility:
>
> #ifndef NO_TRANSLATION
> #define TRANSLATION_OPTS "m:"
> #else
> #define TRANSLATION_OPTS
> #endif
> sopts = "fs:....." TRANS...._OPTS
I am planning on the following the old way (i.e. no new TRANSLATION_OPTS define).
-Don Slutz
> Ian.
>
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH v5 11/17] xenctx: Add -d (--dump-as-stack) <daddr> option to dump memory at daddr as a stack.
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (9 preceding siblings ...)
2014-03-20 19:06 ` [PATCH v5 10/17] xenctx: Add -m (--memory) <maddr> option to dump memory at maddr Don Slutz
@ 2014-03-20 19:06 ` Don Slutz
2014-03-21 14:57 ` Ian Campbell
2014-03-20 19:07 ` [PATCH v5 12/17] xenctx: change is_kernel_text() into kernel_addr() Don Slutz
` (6 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:06 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Don Slutz,
Ian Jackson, Don Slutz, Jan Beulich
Also switch from read_stack_word to read_mem_word since the provided
address may not be aligned.
Signed-off-by: Don Slutz <Don@CloudSwitch.com>
---
tools/xentrace/xenctx.c | 73 +++++++++++++++++++++++++++++++++++--------------
1 file changed, 53 insertions(+), 20 deletions(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index 13f56ed..f77f17e 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -71,7 +71,9 @@ static struct xenctx {
int all_vcpus;
#ifndef NO_TRANSLATION
guest_word_t mem_addr;
+ guest_word_t stk_addr;
int do_memory;
+ int do_stack;
#endif
int self_paused;
xc_dominfo_t dominfo;
@@ -765,15 +767,13 @@ static int print_code(vcpu_guest_context_any_t *ctx, int vcpu)
else
printf("%02x ", *c);
}
- printf("\n");
-
- printf("\n");
+ printf("\n\n\n");
return 0;
}
-static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
+static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width, guest_word_t stk_addr_start)
{
- guest_word_t stack = stack_pointer(ctx);
+ guest_word_t stack = stk_addr_start;
guest_word_t stack_limit;
guest_word_t frame;
guest_word_t word;
@@ -781,11 +781,10 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
if ( width )
xenctx.bytes_per_line = ((xenctx.bytes_per_line + width - 1) / width) * width;
- stack_limit = ((stack_pointer(ctx) + XC_PAGE_SIZE)
+ stack_limit = ((stack + XC_PAGE_SIZE)
& ~((guest_word_t) XC_PAGE_SIZE - 1));
if ( xenctx.multiple_pages > 1 )
stack_limit += (xenctx.multiple_pages - 1) * XC_PAGE_SIZE;
- printf("\n");
if ( xenctx.lines )
{
printf("Stack:\n");
@@ -797,14 +796,17 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
printf("Stack Trace:\n");
else
printf("Call Trace:\n");
- if ( xenctx.tag_call_trace )
- printf(" %*s", width*2, "");
- printf("%c [<", xenctx.stack_trace ? '*' : ' ');
- print_stack_word(instr_pointer(ctx), width);
- printf(">]");
-
- print_symbol(instr_pointer(ctx));
- printf(" <--\n");
+ if ( !xenctx.do_stack )
+ {
+ if ( xenctx.tag_call_trace )
+ printf(" %*s", width*2, "");
+ printf("%c [<", xenctx.stack_trace ? '*' : ' ');
+ print_stack_word(instr_pointer(ctx), width);
+ printf(">]");
+
+ print_symbol(instr_pointer(ctx));
+ printf(" <--\n");
+ }
if (xenctx.frame_ptrs) {
stack = stack_pointer(ctx);
frame = frame_pointer(ctx);
@@ -866,12 +868,12 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
}
}
} else {
- stack = stack_pointer(ctx);
+ stack = stk_addr_start;
while(stack < stack_limit) {
p = map_page(ctx, vcpu, stack);
if (!p)
return -1;
- word = read_stack_word(p, width);
+ word = read_mem_word(ctx, vcpu, stack, width);
if (is_kernel_text(word)) {
if ( xenctx.tag_call_trace )
{
@@ -944,13 +946,19 @@ static void dump_ctx(int vcpu)
print_mem(&ctx, vcpu, guest_word_size, xenctx.mem_addr);
return;
}
+ if ( xenctx.do_stack )
+ {
+ print_stack(&ctx, vcpu, guest_word_size, xenctx.stk_addr);
+ return;
+ }
#endif
print_ctx(&ctx);
#ifndef NO_TRANSLATION
if (print_code(&ctx, vcpu))
return;
if (is_kernel_text(instr_pointer(&ctx)))
- if (print_stack(&ctx, vcpu, guest_word_size))
+ if ( print_stack(&ctx, vcpu, guest_word_size,
+ stack_pointer(&ctx)) )
return;
#endif
}
@@ -1007,6 +1015,8 @@ static void usage(void)
#ifndef NO_TRANSLATION
printf(" -m maddr, --memory=maddr\n");
printf(" dump memory at maddr.\n");
+ printf(" -d daddr, --dump-as-stack=daddr\n");
+ printf(" dump memory as a stack at daddr.\n");
#endif
}
@@ -1015,7 +1025,7 @@ int main(int argc, char **argv)
int ch;
int ret;
#ifndef NO_TRANSLATION
- static const char *sopts = "fs:hak:SCn:b:l:DtTm:";
+ static const char *sopts = "fs:hak:SCn:b:l:DtTm:d:";
#else
static const char *sopts = "fs:hak:SCn:b:l:DtT";
#endif
@@ -1030,6 +1040,7 @@ int main(int argc, char **argv)
{"tag-trace", 0, NULL, 'T'},
#ifndef NO_TRANSLATION
{"memory", 1, NULL, 'm'},
+ {"dump-as-stack", 1, NULL, 'd'},
#endif
{"bytes-per-line", 1, NULL, 'b'},
{"lines", 1, NULL, 'l'},
@@ -1110,6 +1121,11 @@ int main(int argc, char **argv)
xenctx.do_memory = 1;
do_default = 0;
break;
+ case 'd':
+ xenctx.stk_addr = strtoull(optarg, NULL, 0);
+ xenctx.do_stack = 1;
+ do_default = 0;
+ break;
#endif
case 'h':
usage();
@@ -1127,6 +1143,16 @@ int main(int argc, char **argv)
exit(-1);
}
+#ifndef NO_TRANSLATION
+ if ( xenctx.frame_ptrs && xenctx.do_stack )
+ {
+ fprintf(stderr,
+ "%s both --frame-pointers and --dump-as-stack is not supported\n",
+ argv[0]);
+ exit(-1);
+ }
+#endif
+
xenctx.domid = atoi(argv[0]);
if (xenctx.domid==0) {
fprintf(stderr, "cannot trace dom0\n");
@@ -1164,10 +1190,17 @@ int main(int argc, char **argv)
if ( xenctx.do_memory )
{
dump_ctx(vcpu);
- if (xenctx.all_vcpus)
+ if ( xenctx.do_stack || xenctx.all_vcpus )
printf("\n");
}
xenctx.do_memory = 0;
+ if ( xenctx.do_stack )
+ {
+ dump_ctx(vcpu);
+ if ( xenctx.all_vcpus )
+ printf("\n");
+ }
+ xenctx.do_stack = 0;
#endif
if (xenctx.all_vcpus)
dump_all_vcpus();
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v5 11/17] xenctx: Add -d (--dump-as-stack) <daddr> option to dump memory at daddr as a stack.
2014-03-20 19:06 ` [PATCH v5 11/17] xenctx: Add -d (--dump-as-stack) <daddr> option to dump memory at daddr as a stack Don Slutz
@ 2014-03-21 14:57 ` Ian Campbell
2014-03-24 15:22 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 14:57 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
> @@ -797,14 +796,17 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
> printf("Stack Trace:\n");
> else
> printf("Call Trace:\n");
> - if ( xenctx.tag_call_trace )
> - printf(" %*s", width*2, "");
> - printf("%c [<", xenctx.stack_trace ? '*' : ' ');
> - print_stack_word(instr_pointer(ctx), width);
> - printf(">]");
> -
> - print_symbol(instr_pointer(ctx));
> - printf(" <--\n");
> + if ( !xenctx.do_stack )
Why not?
> + {
> + if ( xenctx.tag_call_trace )
> + printf(" %*s", width*2, "");
> + printf("%c [<", xenctx.stack_trace ? '*' : ' ');
> + print_stack_word(instr_pointer(ctx), width);
> + printf(">]");
> +
> + print_symbol(instr_pointer(ctx));
> + printf(" <--\n");
> + }
> if (xenctx.frame_ptrs) {
> stack = stack_pointer(ctx);
> frame = frame_pointer(ctx);
> @@ -944,13 +946,19 @@ static void dump_ctx(int vcpu)
> print_mem(&ctx, vcpu, guest_word_size, xenctx.mem_addr);
> return;
> }
> + if ( xenctx.do_stack )
> + {
> + print_stack(&ctx, vcpu, guest_word_size, xenctx.stk_addr);
> + return;
> + }
It's starting to seem like print_mem and print_stack should be called
from main instead of here. In other words actually have multiple modes
instead of stuffing things in as special cases here.
> ,
> @@ -1110,6 +1121,11 @@ int main(int argc, char **argv)
> xenctx.do_memory = 1;
> do_default = 0;
> break;
> + case 'd':
> + xenctx.stk_addr = strtoull(optarg, NULL, 0);
You can reuse mem_addr here, can't you?
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 11/17] xenctx: Add -d (--dump-as-stack) <daddr> option to dump memory at daddr as a stack.
2014-03-21 14:57 ` Ian Campbell
@ 2014-03-24 15:22 ` Don Slutz
2014-03-27 15:58 ` Ian Campbell
0 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-24 15:22 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On 03/21/14 10:57, Ian Campbell wrote:
> On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
>> @@ -797,14 +796,17 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width)
>> printf("Stack Trace:\n");
>> else
>> printf("Call Trace:\n");
>> - if ( xenctx.tag_call_trace )
>> - printf(" %*s", width*2, "");
>> - printf("%c [<", xenctx.stack_trace ? '*' : ' ');
>> - print_stack_word(instr_pointer(ctx), width);
>> - printf(">]");
>> -
>> - print_symbol(instr_pointer(ctx));
>> - printf(" <--\n");
>> + if ( !xenctx.do_stack )
> Why not?
This code output's rip (instr_pointer(ctx)) which does not apply
in this case.
>> + {
>> + if ( xenctx.tag_call_trace )
>> + printf(" %*s", width*2, "");
>> + printf("%c [<", xenctx.stack_trace ? '*' : ' ');
>> + print_stack_word(instr_pointer(ctx), width);
>> + printf(">]");
>> +
>> + print_symbol(instr_pointer(ctx));
>> + printf(" <--\n");
>> + }
>> if (xenctx.frame_ptrs) {
>> stack = stack_pointer(ctx);
>> frame = frame_pointer(ctx);
>> @@ -944,13 +946,19 @@ static void dump_ctx(int vcpu)
>> print_mem(&ctx, vcpu, guest_word_size, xenctx.mem_addr);
>> return;
>> }
>> + if ( xenctx.do_stack )
>> + {
>> + print_stack(&ctx, vcpu, guest_word_size, xenctx.stk_addr);
>> + return;
>> + }
> It's starting to seem like print_mem and print_stack should be called
> from main instead of here. In other words actually have multiple modes
> instead of tuffing things in as special cases here.
The issue is that ctx (vcpu_guest_context_any_t) does not exist
in main and is needed by map_page() (called from these).
dump_ctx() is the routine that gets this and guest_word_size,
guest_protected_mode, and ctxt_word_size.
And so yes, this part of dump_ctx() could be moved to main
and/or ctx could be made global.
Let me know if I should rework all this.
>> ,
>> @@ -1110,6 +1121,11 @@ int main(int argc, char **argv)
>> xenctx.do_memory = 1;
>> do_default = 0;
>> break;
>> + case 'd':
>> + xenctx.stk_addr = strtoull(optarg, NULL, 0);
> You can reuse mem_addr here, can't you?
>
>
>
Nope. If both -d and -m are specified, then both are done.
-Don Slutz
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 11/17] xenctx: Add -d (--dump-as-stack) <daddr> option to dump memory at daddr as a stack.
2014-03-24 15:22 ` Don Slutz
@ 2014-03-27 15:58 ` Ian Campbell
2014-03-27 17:05 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-27 15:58 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Mon, 2014-03-24 at 11:22 -0400, Don Slutz wrote:
> On 03/21/14 10:57, Ian Campbell wrote:
> > It's starting to seem like print_mem and print_stack should be called
> > from main instead of here. In other words actually have multiple modes
> > instead of tuffing things in as special cases here.
>
> The issue is that ctx (vcpu_guest_context_any_t) does not exist
> in main and is needed by map_page() (called from these).
>
> dump_ctx() is the routine that gets this and guest_word_size,
> guest_protected_mode, and ctxt_word_size.
>
> And so yes, this part of dump_ctx() could be moved to main
> and/or ctx could be made global.
>
> Let me know if I should rework all this.
It does sound like some refactoring might be in order. Lets get this
series put to bed first though.
> >> ,
> >> @@ -1110,6 +1121,11 @@ int main(int argc, char **argv)
> >> xenctx.do_memory = 1;
> >> do_default = 0;
> >> break;
> >> + case 'd':
> >> + xenctx.stk_addr = strtoull(optarg, NULL, 0);
> > You can reuse mem_addr here, can't you?
> >
> >
> >
> Nope. If both -d and -m are specified, then both are done.
Is that useful?
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH v5 11/17] xenctx: Add -d (--dump-as-stack) <daddr> option to dump memory at daddr as a stack.
2014-03-27 15:58 ` Ian Campbell
@ 2014-03-27 17:05 ` Don Slutz
2014-03-27 17:20 ` Ian Campbell
0 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-27 17:05 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On 03/27/14 11:58, Ian Campbell wrote:
> On Mon, 2014-03-24 at 11:22 -0400, Don Slutz wrote:
>> On 03/21/14 10:57, Ian Campbell wrote:
>>> It's starting to seem like print_mem and print_stack should be called
>>> from main instead of here. In other words actually have multiple modes
>>> instead of tuffing things in as special cases here.
>> The issue is that ctx (vcpu_guest_context_any_t) does not exist
>> in main and is needed by map_page() (called from these).
>>
>> dump_ctx() is the routine that gets this and guest_word_size,
>> guest_protected_mode, and ctxt_word_size.
>>
>> And so yes, this part of dump_ctx() could be moved to main
>> and/or ctx could be made global.
>>
>> Let me know if I should rework all this.
> It does sound like some refactoring might be in order. Lets get this
> series put to bed first though.
Ok.
>
>>>> ,
>>>> @@ -1110,6 +1121,11 @@ int main(int argc, char **argv)
>>>> xenctx.do_memory = 1;
>>>> do_default = 0;
>>>> break;
>>>> + case 'd':
>>>> + xenctx.stk_addr = strtoull(optarg, NULL, 0);
>>> You can reuse mem_addr here, can't you?
>>>
>>>
>>>
>> Nope. If both -d and -m are specified, then both are done.
> Is that useful?
>
>
Maybe. I did use it to show the difference between 16 bit and 32 bit output (also v8 stuff). Not clear I would ever use both.
-Don Slutz
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 11/17] xenctx: Add -d (--dump-as-stack) <daddr> option to dump memory at daddr as a stack.
2014-03-27 17:05 ` Don Slutz
@ 2014-03-27 17:20 ` Ian Campbell
2014-03-27 17:49 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-27 17:20 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Thu, 2014-03-27 at 13:05 -0400, Don Slutz wrote:
> On 03/27/14 11:58, Ian Campbell wrote:
> >> Nope. If both -d and -m are specified, then both are done.
> > Is that useful?
> >
> >
>
> Maybe. I did use it to show the difference between 16 bit and 32 bit
> output (also v8 stuff). Not clear I would ever use both.
I don't suppose you fancy writing a manpage for this thing? There's a
document day on Monday (</hint>).
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH v5 11/17] xenctx: Add -d (--dump-as-stack) <daddr> option to dump memory at daddr as a stack.
2014-03-27 17:20 ` Ian Campbell
@ 2014-03-27 17:49 ` Don Slutz
0 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-27 17:49 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On 03/27/14 13:20, Ian Campbell wrote:
> On Thu, 2014-03-27 at 13:05 -0400, Don Slutz wrote:
>> On 03/27/14 11:58, Ian Campbell wrote:
>>
> I don't suppose you fancy writing a manpage for this thing? There's a
> document day on Monday (</hint>).
I guess that can happen. As you can see by my commit messages (and e-maill responses), I am not the best at this.
-Don Slutz
> Ian.
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH v5 12/17] xenctx: change is_kernel_text() into kernel_addr().
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (10 preceding siblings ...)
2014-03-20 19:06 ` [PATCH v5 11/17] xenctx: Add -d (--dump-as-stack) <daddr> option to dump memory at daddr as a stack Don Slutz
@ 2014-03-20 19:07 ` Don Slutz
2014-03-21 15:02 ` Ian Campbell
2014-03-20 19:07 ` [PATCH v5 13/17] xenctx: Add convert of more registers to symbols Don Slutz
` (5 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:07 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Don Slutz,
Ian Jackson, Don Slutz, Jan Beulich
A new enum has been added to allow the caller to determine if this
kernel address is a text or data address. This is currenlty not
used, but will be in the next patch.
Signed-off-by: Don Slutz <Don@CloudSwitch.com>
---
tools/xentrace/xenctx.c | 70 +++++++++++++++++++++++++++++++++++--------------
1 file changed, 51 insertions(+), 19 deletions(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index f77f17e..c574996 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -33,6 +33,15 @@
#define DEFAULT_BYTES_PER_LINE 32
#define DEFAULT_LINES 5
+/* Note: the order of these matter.
+ * NOT_KERNEL_ADDR must be < both KERNEL_DATA_ADDR and KERNEL_TEXT_ADDR.
+ * KERNEL_DATA_ADDR must be < KERNEL_TEXT_ADDR. */
+typedef enum type_of_addr_ {
+ NOT_KERNEL_ADDR,
+ KERNEL_DATA_ADDR,
+ KERNEL_TEXT_ADDR,
+} type_of_addr;
+
#if defined (__i386__) || defined (__x86_64__)
typedef unsigned long long guest_word_t;
#define FMT_32B_WORD "%08llx"
@@ -75,6 +84,7 @@ static struct xenctx {
int do_memory;
int do_stack;
#endif
+ int kernel_start_set;
int self_paused;
xc_dominfo_t dominfo;
} xenctx;
@@ -86,6 +96,7 @@ struct symbol {
} *symbol_table = NULL;
guest_word_t kernel_stext, kernel_etext, kernel_sinittext, kernel_einittext, kernel_hypercallpage;
+guest_word_t kernel_text, kernel_end;
#if defined (__i386__) || defined (__arm__)
unsigned long long kernel_start = 0xc0000000;
@@ -95,22 +106,37 @@ unsigned long long kernel_start = 0xffffffff80000000UL;
unsigned long long kernel_start = 0xffffff8000000000UL;
#endif
-static int is_kernel_text(guest_word_t addr)
+static type_of_addr kernel_addr(guest_word_t addr)
{
- if (symbol_table == NULL)
- return (addr > kernel_start);
+ if ( symbol_table == NULL )
+ {
+ if ( addr > kernel_start )
+ return KERNEL_TEXT_ADDR;
+ else
+ return NOT_KERNEL_ADDR;
+ }
if (addr >= kernel_stext &&
addr <= kernel_etext)
- return 1;
+ return KERNEL_TEXT_ADDR;
if ( kernel_hypercallpage &&
(addr >= kernel_hypercallpage &&
addr <= kernel_hypercallpage + 4096) )
- return 1;
+ return KERNEL_TEXT_ADDR;
if (addr >= kernel_sinittext &&
addr <= kernel_einittext)
- return 1;
- return 0;
+ return KERNEL_TEXT_ADDR;
+ if ( xenctx.kernel_start_set )
+ {
+ if ( addr >= kernel_start &&
+ addr <= kernel_end )
+ return KERNEL_DATA_ADDR;
+ } else {
+ if ( addr >= kernel_text &&
+ addr <= kernel_end )
+ return KERNEL_DATA_ADDR;
+ }
+ return NOT_KERNEL_ADDR;
}
#if 0
@@ -164,11 +190,11 @@ static struct symbol *lookup_symbol(guest_word_t address)
return s->next && s->next->address <= address ? s->next : s;
}
-static void print_symbol(guest_word_t addr)
+static void print_symbol(guest_word_t addr, type_of_addr type)
{
struct symbol *s;
- if (!is_kernel_text(addr))
+ if ( kernel_addr(addr) < type )
return;
s = lookup_symbol(addr);
@@ -248,6 +274,10 @@ static void read_symbol_table(const char *symtab)
kernel_stext = address;
else if (strcmp(p, "_etext") == 0)
kernel_etext = address;
+ else if ( strcmp(p, "_text") == 0 )
+ kernel_text = address;
+ else if ( strcmp(p, "_end") == 0 )
+ kernel_end = address;
else if (strcmp(p, "_sinittext") == 0)
kernel_sinittext = address;
else if (strcmp(p, "_einittext") == 0)
@@ -319,7 +349,7 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
struct cpu_user_regs_x86_32 *regs = &ctx->user_regs;
printf("cs:eip: %04x:%08x", regs->cs, regs->eip);
- print_symbol(regs->eip);
+ print_symbol(regs->eip, KERNEL_TEXT_ADDR);
print_flags(regs->eflags);
printf("ss:esp: %04x:%08x\n", regs->ss, regs->esp);
@@ -348,7 +378,7 @@ static void print_ctx_32on64(vcpu_guest_context_x86_64_t *ctx)
struct cpu_user_regs_x86_64 *regs = &ctx->user_regs;
printf("cs:eip: %04x:%08x", regs->cs, (uint32_t)regs->eip);
- print_symbol((uint32_t)regs->eip);
+ print_symbol((uint32_t)regs->eip, KERNEL_TEXT_ADDR);
print_flags((uint32_t)regs->eflags);
printf("ss:esp: %04x:%08x\n", regs->ss, (uint32_t)regs->esp);
@@ -377,7 +407,7 @@ static void print_ctx_64(vcpu_guest_context_x86_64_t *ctx)
struct cpu_user_regs_x86_64 *regs = &ctx->user_regs;
printf("rip: %016"PRIx64, regs->rip);
- print_symbol(regs->rip);
+ print_symbol(regs->rip, KERNEL_TEXT_ADDR);
print_flags(regs->rflags);
printf("rsp: %016"PRIx64"\n", regs->rsp);
@@ -475,7 +505,7 @@ static void print_ctx_32(vcpu_guest_context_t *ctx)
vcpu_guest_core_regs_t *regs = &ctx->user_regs;
printf("PC: %08"PRIx32, regs->pc32);
- print_symbol(regs->pc32);
+ print_symbol(regs->pc32, KERNEL_TEXT_ADDR);
printf("\n");
printf("CPSR: %08"PRIx32"\n", regs->cpsr);
printf("USR: SP:%08"PRIx32" LR:%08"PRIx32"\n",
@@ -527,7 +557,7 @@ static void print_ctx_64(vcpu_guest_context_t *ctx)
vcpu_guest_core_regs_t *regs = &ctx->user_regs;
printf("PC: %016"PRIx64, regs->pc64);
- print_symbol(regs->pc64);
+ print_symbol(regs->pc64, KERNEL_TEXT_ADDR);
printf("\n");
printf("LR: %016"PRIx64"\n", regs->x30);
@@ -804,7 +834,7 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width, guest
print_stack_word(instr_pointer(ctx), width);
printf(">]");
- print_symbol(instr_pointer(ctx));
+ print_symbol(instr_pointer(ctx), KERNEL_TEXT_ADDR);
printf(" <--\n");
}
if (xenctx.frame_ptrs) {
@@ -862,7 +892,7 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width, guest
}
print_stack_word(word, width);
printf(">]");
- print_symbol(word);
+ print_symbol(word, KERNEL_TEXT_ADDR);
printf("\n");
stack += width;
}
@@ -874,7 +904,8 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width, guest
if (!p)
return -1;
word = read_mem_word(ctx, vcpu, stack, width);
- if (is_kernel_text(word)) {
+ if ( kernel_addr(word) >= KERNEL_TEXT_ADDR )
+ {
if ( xenctx.tag_call_trace )
{
print_stack_word(stack, width);
@@ -884,7 +915,7 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width, guest
}
print_stack_word(word, width);
printf(">]");
- print_symbol(word);
+ print_symbol(word, KERNEL_TEXT_ADDR);
printf("\n");
} else if (xenctx.stack_trace) {
if ( xenctx.tag_call_trace )
@@ -956,7 +987,7 @@ static void dump_ctx(int vcpu)
#ifndef NO_TRANSLATION
if (print_code(&ctx, vcpu))
return;
- if (is_kernel_text(instr_pointer(&ctx)))
+ if ( kernel_addr(instr_pointer(&ctx)) >= KERNEL_TEXT_ADDR )
if ( print_stack(&ctx, vcpu, guest_word_size,
stack_pointer(&ctx)) )
return;
@@ -1114,6 +1145,7 @@ int main(int argc, char **argv)
break;
case 'k':
kernel_start = strtoull(optarg, NULL, 0);
+ xenctx.kernel_start_set = 1;
break;
#ifndef NO_TRANSLATION
case 'm':
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v5 12/17] xenctx: change is_kernel_text() into kernel_addr().
2014-03-20 19:07 ` [PATCH v5 12/17] xenctx: change is_kernel_text() into kernel_addr() Don Slutz
@ 2014-03-21 15:02 ` Ian Campbell
2014-03-21 17:45 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 15:02 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
> A new enum has been added to allow the caller to determine if this
> kernel address is a text or data address. This is currenlty not
> used, but will be in the next patch.
>
> Signed-off-by: Don Slutz <Don@CloudSwitch.com>
> ---
> tools/xentrace/xenctx.c | 70 +++++++++++++++++++++++++++++++++++--------------
> 1 file changed, 51 insertions(+), 19 deletions(-)
>
> diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
> index f77f17e..c574996 100644
> --- a/tools/xentrace/xenctx.c
> +++ b/tools/xentrace/xenctx.c
> @@ -33,6 +33,15 @@
> #define DEFAULT_BYTES_PER_LINE 32
> #define DEFAULT_LINES 5
>
> +/* Note: the order of these matter.
> + * NOT_KERNEL_ADDR must be < both KERNEL_DATA_ADDR and KERNEL_TEXT_ADDR.
> + * KERNEL_DATA_ADDR must be < KERNEL_TEXT_ADDR. */
> +typedef enum type_of_addr_ {
> + NOT_KERNEL_ADDR,
AKA a User Address?
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 12/17] xenctx: change is_kernel_text() into kernel_addr().
2014-03-21 15:02 ` Ian Campbell
@ 2014-03-21 17:45 ` Don Slutz
2014-03-24 22:23 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-21 17:45 UTC (permalink / raw)
To: Ian Campbell
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
Don Slutz, xen-devel, Jan Beulich
On 03/21/14 11:02, Ian Campbell wrote:
> On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
>> A new enum has been added to allow the caller to determine if this
>> kernel address is a text or data address. This is currenlty not
>> used, but will be in the next patch.
>>
>> Signed-off-by: Don Slutz <Don@CloudSwitch.com>
>> ---
>> tools/xentrace/xenctx.c | 70 +++++++++++++++++++++++++++++++++++--------------
>> 1 file changed, 51 insertions(+), 19 deletions(-)
>>
>> diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
>> index f77f17e..c574996 100644
>> --- a/tools/xentrace/xenctx.c
>> +++ b/tools/xentrace/xenctx.c
>> @@ -33,6 +33,15 @@
>> #define DEFAULT_BYTES_PER_LINE 32
>> #define DEFAULT_LINES 5
>>
>> +/* Note: the order of these matter.
>> + * NOT_KERNEL_ADDR must be < both KERNEL_DATA_ADDR and KERNEL_TEXT_ADDR.
>> + * KERNEL_DATA_ADDR must be < KERNEL_TEXT_ADDR. */
>> +typedef enum type_of_addr_ {
>> + NOT_KERNEL_ADDR,
> AKA a User Address?
>
>
Yes.
-Don Slutz
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 12/17] xenctx: change is_kernel_text() into kernel_addr().
2014-03-21 17:45 ` Don Slutz
@ 2014-03-24 22:23 ` Don Slutz
2014-03-25 9:13 ` Jan Beulich
2014-03-27 15:59 ` Ian Campbell
0 siblings, 2 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-24 22:23 UTC (permalink / raw)
To: Don Slutz, Ian Campbell
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On 03/21/14 13:45, Don Slutz wrote:
>
> On 03/21/14 11:02, Ian Campbell wrote:
>> On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
>>> A new enum has been added to allow the caller to determine if this
>>> kernel address is a text or data address. This is currenlty not
>>> used, but will be in the next patch.
>>>
>>> Signed-off-by: Don Slutz <Don@CloudSwitch.com>
>>> ---
>>> tools/xentrace/xenctx.c | 70 +++++++++++++++++++++++++++++++++++--------------
>>> 1 file changed, 51 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
>>> index f77f17e..c574996 100644
>>> --- a/tools/xentrace/xenctx.c
>>> +++ b/tools/xentrace/xenctx.c
>>> @@ -33,6 +33,15 @@
>>> #define DEFAULT_BYTES_PER_LINE 32
>>> #define DEFAULT_LINES 5
>>> +/* Note: the order of these matter.
>>> + * NOT_KERNEL_ADDR must be < both KERNEL_DATA_ADDR and KERNEL_TEXT_ADDR.
>>> + * KERNEL_DATA_ADDR must be < KERNEL_TEXT_ADDR. */
>>> +typedef enum type_of_addr_ {
>>> + NOT_KERNEL_ADDR,
>> AKA a User Address?
>>
>>
>
> Yes.
> -Don Slutz
>
I have now found out this is not correct. kernel module addresses are also NOT_KERNEL_ADDR. Not sure what needs to be done here. Also turn out that:
ffffffffff600000 T vgettimeofday
ffffffffff60000f t vsysc2
ffffffffff600180 D __xtime_lock
ffffffffff600190 D __vxtime
ffffffffff6001c0 D __vgetcpu_mode
ffffffffff6001d0 D __wall_jiffies
ffffffffff6001e0 D __sys_tz
ffffffffff6001f0 D __sysctl_vsyscall
ffffffffff600200 D __xtime
ffffffffff600280 D __jiffies
ffffffffff600400 T vtime
ffffffffff60040e t vsysc1
ffffffffff600800 T vgetcpu
ffffffffff600c00 T venosys_1
will not be matched. Not sure what is the right thing to do here.
-Don Slutz
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 12/17] xenctx: change is_kernel_text() into kernel_addr().
2014-03-24 22:23 ` Don Slutz
@ 2014-03-25 9:13 ` Jan Beulich
2014-03-27 15:59 ` Ian Campbell
1 sibling, 0 replies; 77+ messages in thread
From: Jan Beulich @ 2014-03-25 9:13 UTC (permalink / raw)
To: Don Slutz
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Don Slutz,
Ian Jackson, xen-devel
>>> On 24.03.14 at 23:23, <dslutz@verizon.com> wrote:
> Also turn out that:
>
> ffffffffff600000 T vgettimeofday
> ffffffffff60000f t vsysc2
> ffffffffff600180 D __xtime_lock
> ffffffffff600190 D __vxtime
> ffffffffff6001c0 D __vgetcpu_mode
> ffffffffff6001d0 D __wall_jiffies
> ffffffffff6001e0 D __sys_tz
> ffffffffff6001f0 D __sysctl_vsyscall
> ffffffffff600200 D __xtime
> ffffffffff600280 D __jiffies
> ffffffffff600400 T vtime
> ffffffffff60040e t vsysc1
> ffffffffff600800 T vgetcpu
> ffffffffff600c00 T venosys_1
>
> will not be matched. Not sure what is the right thing to do here.
These aren't really kernel addresses, i.e. you wouldn't want them
recognized as such in kernel stack dumps.
Jan
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH v5 12/17] xenctx: change is_kernel_text() into kernel_addr().
2014-03-24 22:23 ` Don Slutz
2014-03-25 9:13 ` Jan Beulich
@ 2014-03-27 15:59 ` Ian Campbell
1 sibling, 0 replies; 77+ messages in thread
From: Ian Campbell @ 2014-03-27 15:59 UTC (permalink / raw)
To: Don Slutz
Cc: Stefano Stabellini, George Dunlap, Don Slutz, Ian Jackson,
xen-devel, Jan Beulich
On Mon, 2014-03-24 at 18:23 -0400, Don Slutz wrote:
> I have now found out this is not correct. kernel module addresses are
> also NOT_KERNEL_ADDR. Not sure what needs to be done here.
There probably isn't that much you can do without a great deal more
introspection into the guest kernel, including kernel specific
knowledge.
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH v5 13/17] xenctx: Add convert of more registers to symbols
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (11 preceding siblings ...)
2014-03-20 19:07 ` [PATCH v5 12/17] xenctx: change is_kernel_text() into kernel_addr() Don Slutz
@ 2014-03-20 19:07 ` Don Slutz
2014-03-21 10:24 ` Jan Beulich
2014-03-21 15:07 ` [PATCH v5 " Ian Campbell
2014-03-20 19:07 ` [PATCH v5 14/17] xenctx: Add output of vcpu value and state for --all-vcpus Don Slutz
` (4 subsequent siblings)
17 siblings, 2 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:07 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Ian Jackson,
Don Slutz, Jan Beulich
For example can change:
gs: 0000 @ ffffffff803ac000/0000000000000000
to
gs: 0000 @ ffffffff803ac000/0000000000000000 boot_cpu_pda/
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
v5: Add reg_is_addr_mask.
tools/xentrace/xenctx.c | 53 ++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 41 insertions(+), 12 deletions(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index c574996..5dfa7e6 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -330,17 +330,29 @@ static void print_flags(uint64_t flags)
printf("\n");
}
-static void print_special(void *regs, const char *name, unsigned int mask, int width)
+static void print_special(void *regs, const char *name, unsigned int mask,
+ uint64_t reg_is_addr_mask[], int width)
{
unsigned int i;
printf("\n");
for (i = 0; mask; mask >>= 1, ++i)
if (mask & 1) {
- if (width == 4)
- printf("%s%u: %08"PRIx32"\n", name, i, ((uint32_t *) regs)[i]);
+ if ( width == 4 )
+ {
+ printf("%s%u: %08"PRIx32, name, i, ((uint32_t *) regs)[i]);
+ if ( reg_is_addr_mask[i] )
+ print_symbol(reg_is_addr_mask[i] & ((uint32_t *) regs)[i],
+ KERNEL_DATA_ADDR);
+ }
else
- printf("%s%u: %08"PRIx64"\n", name, i, ((uint64_t *) regs)[i]);
+ {
+ printf("%s%u: %016"PRIx64, name, i, ((uint64_t *) regs)[i]);
+ if ( reg_is_addr_mask[i] )
+ print_symbol(reg_is_addr_mask[i] & ((uint64_t *) regs)[i],
+ KERNEL_DATA_ADDR);
+ }
+ printf("\n");
}
}
@@ -368,8 +380,11 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
printf(" gs: %04x\n", regs->gs);
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 4);
- print_special(ctx->debugreg, "dr", 0xcf, 4);
+ uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
+ uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
+
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 4);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 4);
}
}
@@ -397,8 +412,11 @@ static void print_ctx_32on64(vcpu_guest_context_x86_64_t *ctx)
printf(" gs: %04x\n", regs->gs);
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 4);
- print_special(ctx->debugreg, "dr", 0xcf, 4);
+ uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
+ uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
+
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 4);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 4);
}
}
@@ -436,13 +454,24 @@ static void print_ctx_64(vcpu_guest_context_x86_64_t *ctx)
printf(" ds: %04x\t", regs->ds);
printf(" es: %04x\n", regs->es);
- printf(" fs: %04x @ %016"PRIx64"\n", regs->fs, ctx->fs_base);
- printf(" gs: %04x @ %016"PRIx64"/%016"PRIx64"\n", regs->gs,
+ printf(" fs: %04x @ %016"PRIx64, regs->fs, ctx->fs_base);
+ print_symbol(ctx->fs_base, KERNEL_DATA_ADDR);
+ printf("\n");
+ printf(" gs: %04x @ %016"PRIx64"/%016"PRIx64, regs->gs,
ctx->gs_base_kernel, ctx->gs_base_user);
+ if (symbol_table) {
+ print_symbol(ctx->gs_base_kernel, KERNEL_DATA_ADDR);
+ printf("/");
+ print_symbol(ctx->gs_base_user, KERNEL_DATA_ADDR);
+ }
+ printf("\n");
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 8);
- print_special(ctx->debugreg, "dr", 0xcf, 8);
+ uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
+ uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
+
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 8);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 8);
}
}
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v5 13/17] xenctx: Add convert of more registers to symbols
2014-03-20 19:07 ` [PATCH v5 13/17] xenctx: Add convert of more registers to symbols Don Slutz
@ 2014-03-21 10:24 ` Jan Beulich
2014-03-21 12:34 ` Don Slutz
2014-03-21 15:07 ` [PATCH v5 " Ian Campbell
1 sibling, 1 reply; 77+ messages in thread
From: Jan Beulich @ 2014-03-21 10:24 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, xen-devel, Ian Jackson, Ian Campbell, Stefano Stabellini
>>> On 20.03.14 at 20:07, Don Slutz <dslutz@verizon.com> wrote:
> @@ -368,8 +380,11 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
> printf(" gs: %04x\n", regs->gs);
>
> if (xenctx.disp_all) {
> - print_special(ctx->ctrlreg, "cr", 0x1d, 4);
> - print_special(ctx->debugreg, "dr", 0xcf, 4);
> + uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
> + uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
So you've got a total of three of those. Why can't they be static
const at file scope, and be used in all three places?
Also, using C99 (available as gcc extension) here may make this
a bit more legible:
static const uint64_t cr_reg_mask[5] = { [2] = ~UINT64_C(0) };
static const uint64_t dr_reg_mask[8] = { [0 ... 3] = ~UINT64_C(0) };
Jan
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 13/17] xenctx: Add convert of more registers to symbols
2014-03-21 10:24 ` Jan Beulich
@ 2014-03-21 12:34 ` Don Slutz
2014-03-21 14:11 ` [PATCH v6 " Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-21 12:34 UTC (permalink / raw)
To: Jan Beulich
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Ian Jackson,
Don Slutz, xen-devel
On 03/21/14 06:24, Jan Beulich wrote:
>>>> On 20.03.14 at 20:07, Don Slutz <dslutz@verizon.com> wrote:
>> @@ -368,8 +380,11 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
>> printf(" gs: %04x\n", regs->gs);
>>
>> if (xenctx.disp_all) {
>> - print_special(ctx->ctrlreg, "cr", 0x1d, 4);
>> - print_special(ctx->debugreg, "dr", 0xcf, 4);
>> + uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
>> + uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
> So you've got a total of three of those. Why can't they be static
> const at file scope, and be used in all three places?
Looks like they can.
> Also, using C99 (available as gcc extension) here may make this
> a bit more legible:
>
> static const uint64_t cr_reg_mask[5] = { [2] = ~UINT64_C(0) };
> static const uint64_t dr_reg_mask[8] = { [0 ... 3] = ~UINT64_C(0) };
Will test that it works on CentOS 5.10 and a send a v6 of just this.
-Don Slutz
> Jan
>
^ permalink raw reply [flat|nested] 77+ messages in thread* [PATCH v6 13/17] xenctx: Add convert of more registers to symbols
2014-03-21 12:34 ` Don Slutz
@ 2014-03-21 14:11 ` Don Slutz
2014-03-21 14:45 ` Jan Beulich
2014-03-21 15:03 ` [PATCH v6 " Ian Campbell
0 siblings, 2 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-21 14:11 UTC (permalink / raw)
To: Jan Beulich
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Ian Jackson,
Don Slutz, xen-devel
[-- Attachment #1: Type: text/plain, Size: 4679 bytes --]
On 03/21/14 08:34, Don Slutz wrote:
> On 03/21/14 06:24, Jan Beulich wrote:
>>
>
> Looks like they can.
>
>> Also, using C99 (available as gcc extension) here may make this
>> a bit more legible:
>>
>> static const uint64_t cr_reg_mask[5] = { [2] = ~UINT64_C(0) };
>> static const uint64_t dr_reg_mask[8] = { [0 ... 3] = ~UINT64_C(0) };
>
> Will test that it works on CentOS 5.10 and a send a v6 of just this.
>
> -Don Slutz
>
>> Jan
>>
>
Here is v6:
From e418d907d55cdb5361879bbaea0c2b96443df846 Mon Sep 17 00:00:00 2001
From: Don Slutz <dslutz@verizon.com>
Date: Sat, 9 Nov 2013 20:32:40 -0500
Subject: [PATCH 13/17] xenctx: Add convert of more registers to symbols
For example can change:
gs: 0000 @ ffffffff803ac000/0000000000000000
to
gs: 0000 @ ffffffff803ac000/0000000000000000 boot_cpu_pda/
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
tools/xentrace/xenctx.c | 47
+++++++++++++++++++++++++++++++++++------------
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index c574996..88dcaf7 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -106,6 +106,9 @@ unsigned long long kernel_start = 0xffffffff80000000UL;
unsigned long long kernel_start = 0xffffff8000000000UL;
#endif
+static const uint64_t cr_reg_mask[5] = { [2] = ~UINT64_C(0) };
+static const uint64_t dr_reg_mask[8] = { [0 ... 3] = ~UINT64_C(0) };
+
static type_of_addr kernel_addr(guest_word_t addr)
{
if ( symbol_table == NULL )
@@ -330,17 +333,29 @@ static void print_flags(uint64_t flags)
printf("\n");
}
-static void print_special(void *regs, const char *name, unsigned int
mask, int width)
+static void print_special(void *regs, const char *name, unsigned int mask,
+ const uint64_t reg_is_addr_mask[], int width)
{
unsigned int i;
printf("\n");
for (i = 0; mask; mask >>= 1, ++i)
if (mask & 1) {
- if (width == 4)
- printf("%s%u: %08"PRIx32"\n", name, i, ((uint32_t *)
regs)[i]);
+ if ( width == 4 )
+ {
+ printf("%s%u: %08"PRIx32, name, i, ((uint32_t *) regs)[i]);
+ if ( reg_is_addr_mask[i] )
+ print_symbol(reg_is_addr_mask[i] & ((uint32_t *)
regs)[i],
+ KERNEL_DATA_ADDR);
+ }
else
- printf("%s%u: %08"PRIx64"\n", name, i, ((uint64_t *)
regs)[i]);
+ {
+ printf("%s%u: %016"PRIx64, name, i, ((uint64_t *)
regs)[i]);
+ if ( reg_is_addr_mask[i] )
+ print_symbol(reg_is_addr_mask[i] & ((uint64_t *)
regs)[i],
+ KERNEL_DATA_ADDR);
+ }
+ printf("\n");
}
}
@@ -368,8 +383,8 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t
*ctx)
printf(" gs: %04x\n", regs->gs);
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 4);
- print_special(ctx->debugreg, "dr", 0xcf, 4);
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 4);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 4);
}
}
@@ -397,8 +412,8 @@ static void
print_ctx_32on64(vcpu_guest_context_x86_64_t *ctx)
printf(" gs: %04x\n", regs->gs);
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 4);
- print_special(ctx->debugreg, "dr", 0xcf, 4);
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 4);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 4);
}
}
@@ -436,13 +451,21 @@ static void
print_ctx_64(vcpu_guest_context_x86_64_t *ctx)
printf(" ds: %04x\t", regs->ds);
printf(" es: %04x\n", regs->es);
- printf(" fs: %04x @ %016"PRIx64"\n", regs->fs, ctx->fs_base);
- printf(" gs: %04x @ %016"PRIx64"/%016"PRIx64"\n", regs->gs,
+ printf(" fs: %04x @ %016"PRIx64, regs->fs, ctx->fs_base);
+ print_symbol(ctx->fs_base, KERNEL_DATA_ADDR);
+ printf("\n");
+ printf(" gs: %04x @ %016"PRIx64"/%016"PRIx64, regs->gs,
ctx->gs_base_kernel, ctx->gs_base_user);
+ if (symbol_table) {
+ print_symbol(ctx->gs_base_kernel, KERNEL_DATA_ADDR);
+ printf("/");
+ print_symbol(ctx->gs_base_user, KERNEL_DATA_ADDR);
+ }
+ printf("\n");
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 8);
- print_special(ctx->debugreg, "dr", 0xcf, 8);
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 8);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 8);
}
}
--
1.7.11.7
-Don Slutz
[-- Attachment #2: 0013-xenctx-Add-convert-of-more-registers-to-symbols.patch --]
[-- Type: text/x-patch, Size: 4176 bytes --]
>From e418d907d55cdb5361879bbaea0c2b96443df846 Mon Sep 17 00:00:00 2001
From: Don Slutz <dslutz@verizon.com>
Date: Sat, 9 Nov 2013 20:32:40 -0500
Subject: [PATCH 13/17] xenctx: Add convert of more registers to symbols
For example can change:
gs: 0000 @ ffffffff803ac000/0000000000000000
to
gs: 0000 @ ffffffff803ac000/0000000000000000 boot_cpu_pda/
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
| 47 +++++++++++++++++++++++++++++++++++------------
1 file changed, 35 insertions(+), 12 deletions(-)
--git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index c574996..88dcaf7 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -106,6 +106,9 @@ unsigned long long kernel_start = 0xffffffff80000000UL;
unsigned long long kernel_start = 0xffffff8000000000UL;
#endif
+static const uint64_t cr_reg_mask[5] = { [2] = ~UINT64_C(0) };
+static const uint64_t dr_reg_mask[8] = { [0 ... 3] = ~UINT64_C(0) };
+
static type_of_addr kernel_addr(guest_word_t addr)
{
if ( symbol_table == NULL )
@@ -330,17 +333,29 @@ static void print_flags(uint64_t flags)
printf("\n");
}
-static void print_special(void *regs, const char *name, unsigned int mask, int width)
+static void print_special(void *regs, const char *name, unsigned int mask,
+ const uint64_t reg_is_addr_mask[], int width)
{
unsigned int i;
printf("\n");
for (i = 0; mask; mask >>= 1, ++i)
if (mask & 1) {
- if (width == 4)
- printf("%s%u: %08"PRIx32"\n", name, i, ((uint32_t *) regs)[i]);
+ if ( width == 4 )
+ {
+ printf("%s%u: %08"PRIx32, name, i, ((uint32_t *) regs)[i]);
+ if ( reg_is_addr_mask[i] )
+ print_symbol(reg_is_addr_mask[i] & ((uint32_t *) regs)[i],
+ KERNEL_DATA_ADDR);
+ }
else
- printf("%s%u: %08"PRIx64"\n", name, i, ((uint64_t *) regs)[i]);
+ {
+ printf("%s%u: %016"PRIx64, name, i, ((uint64_t *) regs)[i]);
+ if ( reg_is_addr_mask[i] )
+ print_symbol(reg_is_addr_mask[i] & ((uint64_t *) regs)[i],
+ KERNEL_DATA_ADDR);
+ }
+ printf("\n");
}
}
@@ -368,8 +383,8 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
printf(" gs: %04x\n", regs->gs);
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 4);
- print_special(ctx->debugreg, "dr", 0xcf, 4);
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 4);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 4);
}
}
@@ -397,8 +412,8 @@ static void print_ctx_32on64(vcpu_guest_context_x86_64_t *ctx)
printf(" gs: %04x\n", regs->gs);
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 4);
- print_special(ctx->debugreg, "dr", 0xcf, 4);
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 4);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 4);
}
}
@@ -436,13 +451,21 @@ static void print_ctx_64(vcpu_guest_context_x86_64_t *ctx)
printf(" ds: %04x\t", regs->ds);
printf(" es: %04x\n", regs->es);
- printf(" fs: %04x @ %016"PRIx64"\n", regs->fs, ctx->fs_base);
- printf(" gs: %04x @ %016"PRIx64"/%016"PRIx64"\n", regs->gs,
+ printf(" fs: %04x @ %016"PRIx64, regs->fs, ctx->fs_base);
+ print_symbol(ctx->fs_base, KERNEL_DATA_ADDR);
+ printf("\n");
+ printf(" gs: %04x @ %016"PRIx64"/%016"PRIx64, regs->gs,
ctx->gs_base_kernel, ctx->gs_base_user);
+ if (symbol_table) {
+ print_symbol(ctx->gs_base_kernel, KERNEL_DATA_ADDR);
+ printf("/");
+ print_symbol(ctx->gs_base_user, KERNEL_DATA_ADDR);
+ }
+ printf("\n");
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 8);
- print_special(ctx->debugreg, "dr", 0xcf, 8);
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 8);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 8);
}
}
--
1.7.11.7
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v6 13/17] xenctx: Add convert of more registers to symbols
2014-03-21 14:11 ` [PATCH v6 " Don Slutz
@ 2014-03-21 14:45 ` Jan Beulich
2014-03-21 17:43 ` [PATCH v7 " Don Slutz
2014-03-21 15:03 ` [PATCH v6 " Ian Campbell
1 sibling, 1 reply; 77+ messages in thread
From: Jan Beulich @ 2014-03-21 14:45 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, xen-devel, Ian Jackson, Ian Campbell, Stefano Stabellini
>>> On 21.03.14 at 15:11, Don Slutz <dslutz@verizon.com> wrote:
> --- a/tools/xentrace/xenctx.c
> +++ b/tools/xentrace/xenctx.c
> @@ -106,6 +106,9 @@ unsigned long long kernel_start = 0xffffffff80000000UL;
> unsigned long long kernel_start = 0xffffff8000000000UL;
> #endif
>
> +static const uint64_t cr_reg_mask[5] = { [2] = ~UINT64_C(0) };
> +static const uint64_t dr_reg_mask[8] = { [0 ... 3] = ~UINT64_C(0) };
This should be in an x86-specific section (preferably be added to
an existing one rather than adding yet another).
Also the patch came through line wrapped.
Jan
^ permalink raw reply [flat|nested] 77+ messages in thread* [PATCH v7 13/17] xenctx: Add convert of more registers to symbols
2014-03-21 14:45 ` Jan Beulich
@ 2014-03-21 17:43 ` Don Slutz
2014-03-24 10:51 ` Ian Campbell
0 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-21 17:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Ian Jackson,
Don Slutz, xen-devel
[-- Attachment #1: Type: text/plain, Size: 4943 bytes --]
On 03/21/14 10:45, Jan Beulich wrote:
>>>> On 21.03.14 at 15:11, Don Slutz <dslutz@verizon.com> wrote:
>> --- a/tools/xentrace/xenctx.c
>> +++ b/tools/xentrace/xenctx.c
>> @@ -106,6 +106,9 @@ unsigned long long kernel_start = 0xffffffff80000000UL;
>> unsigned long long kernel_start = 0xffffff8000000000UL;
>> #endif
>>
>> +static const uint64_t cr_reg_mask[5] = { [2] = ~UINT64_C(0) };
>> +static const uint64_t dr_reg_mask[8] = { [0 ... 3] = ~UINT64_C(0) };
> This should be in an x86-specific section (preferably be added to
> an existing one rather than adding yet another).
>
> Also the patch came through line wrapped.
>
> Jan
>
Here is v7 with them moved (and hopefully not line wrapped):
From bc8a441b718e302128f59a53908a1c05afca8680 Mon Sep 17 00:00:00 2001
From: Don Slutz <dslutz@verizon.com>
Date: Sat, 9 Nov 2013 20:32:40 -0500
Subject: [PATCH 13/17] xenctx: Add convert of more registers to symbols
For example can change:
gs: 0000 @ ffffffff803ac000/0000000000000000
to
gs: 0000 @ ffffffff803ac000/0000000000000000 boot_cpu_pda/
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
tools/xentrace/xenctx.c | 46
++++++++++++++++++++++++++++++++++------------
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index c574996..e6e41b6 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -43,6 +43,8 @@ typedef enum type_of_addr_ {
} type_of_addr;
#if defined (__i386__) || defined (__x86_64__)
+static const uint64_t cr_reg_mask[5] = { [2] = ~UINT64_C(0) };
+static const uint64_t dr_reg_mask[8] = { [0 ... 3] = ~UINT64_C(0) };
typedef unsigned long long guest_word_t;
#define FMT_32B_WORD "%08llx"
#define FMT_64B_WORD "%016llx"
@@ -330,17 +332,29 @@ static void print_flags(uint64_t flags)
printf("\n");
}
-static void print_special(void *regs, const char *name, unsigned int
mask, int width)
+static void print_special(void *regs, const char *name, unsigned int mask,
+ const uint64_t reg_is_addr_mask[], int width)
{
unsigned int i;
printf("\n");
for (i = 0; mask; mask >>= 1, ++i)
if (mask & 1) {
- if (width == 4)
- printf("%s%u: %08"PRIx32"\n", name, i, ((uint32_t *)
regs)[i]);
+ if ( width == 4 )
+ {
+ printf("%s%u: %08"PRIx32, name, i, ((uint32_t *) regs)[i]);
+ if ( reg_is_addr_mask[i] )
+ print_symbol(reg_is_addr_mask[i] & ((uint32_t *)
regs)[i],
+ KERNEL_DATA_ADDR);
+ }
else
- printf("%s%u: %08"PRIx64"\n", name, i, ((uint64_t *)
regs)[i]);
+ {
+ printf("%s%u: %016"PRIx64, name, i, ((uint64_t *)
regs)[i]);
+ if ( reg_is_addr_mask[i] )
+ print_symbol(reg_is_addr_mask[i] & ((uint64_t *)
regs)[i],
+ KERNEL_DATA_ADDR);
+ }
+ printf("\n");
}
}
@@ -368,8 +382,8 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t
*ctx)
printf(" gs: %04x\n", regs->gs);
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 4);
- print_special(ctx->debugreg, "dr", 0xcf, 4);
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 4);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 4);
}
}
@@ -397,8 +411,8 @@ static void
print_ctx_32on64(vcpu_guest_context_x86_64_t *ctx)
printf(" gs: %04x\n", regs->gs);
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 4);
- print_special(ctx->debugreg, "dr", 0xcf, 4);
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 4);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 4);
}
}
@@ -436,13 +450,21 @@ static void
print_ctx_64(vcpu_guest_context_x86_64_t *ctx)
printf(" ds: %04x\t", regs->ds);
printf(" es: %04x\n", regs->es);
- printf(" fs: %04x @ %016"PRIx64"\n", regs->fs, ctx->fs_base);
- printf(" gs: %04x @ %016"PRIx64"/%016"PRIx64"\n", regs->gs,
+ printf(" fs: %04x @ %016"PRIx64, regs->fs, ctx->fs_base);
+ print_symbol(ctx->fs_base, KERNEL_DATA_ADDR);
+ printf("\n");
+ printf(" gs: %04x @ %016"PRIx64"/%016"PRIx64, regs->gs,
ctx->gs_base_kernel, ctx->gs_base_user);
+ if (symbol_table) {
+ print_symbol(ctx->gs_base_kernel, KERNEL_DATA_ADDR);
+ printf("/");
+ print_symbol(ctx->gs_base_user, KERNEL_DATA_ADDR);
+ }
+ printf("\n");
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 8);
- print_special(ctx->debugreg, "dr", 0xcf, 8);
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 8);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 8);
}
}
--
1.7.11.7
Attached also just in case.
-Don Slutz
[-- Attachment #2: 0013-xenctx-Add-convert-of-more-registers-to-symbols.patch --]
[-- Type: text/x-patch, Size: 4161 bytes --]
>From bc8a441b718e302128f59a53908a1c05afca8680 Mon Sep 17 00:00:00 2001
From: Don Slutz <dslutz@verizon.com>
Date: Sat, 9 Nov 2013 20:32:40 -0500
Subject: [PATCH 13/17] xenctx: Add convert of more registers to symbols
For example can change:
gs: 0000 @ ffffffff803ac000/0000000000000000
to
gs: 0000 @ ffffffff803ac000/0000000000000000 boot_cpu_pda/
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
| 46 ++++++++++++++++++++++++++++++++++------------
1 file changed, 34 insertions(+), 12 deletions(-)
--git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index c574996..e6e41b6 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -43,6 +43,8 @@ typedef enum type_of_addr_ {
} type_of_addr;
#if defined (__i386__) || defined (__x86_64__)
+static const uint64_t cr_reg_mask[5] = { [2] = ~UINT64_C(0) };
+static const uint64_t dr_reg_mask[8] = { [0 ... 3] = ~UINT64_C(0) };
typedef unsigned long long guest_word_t;
#define FMT_32B_WORD "%08llx"
#define FMT_64B_WORD "%016llx"
@@ -330,17 +332,29 @@ static void print_flags(uint64_t flags)
printf("\n");
}
-static void print_special(void *regs, const char *name, unsigned int mask, int width)
+static void print_special(void *regs, const char *name, unsigned int mask,
+ const uint64_t reg_is_addr_mask[], int width)
{
unsigned int i;
printf("\n");
for (i = 0; mask; mask >>= 1, ++i)
if (mask & 1) {
- if (width == 4)
- printf("%s%u: %08"PRIx32"\n", name, i, ((uint32_t *) regs)[i]);
+ if ( width == 4 )
+ {
+ printf("%s%u: %08"PRIx32, name, i, ((uint32_t *) regs)[i]);
+ if ( reg_is_addr_mask[i] )
+ print_symbol(reg_is_addr_mask[i] & ((uint32_t *) regs)[i],
+ KERNEL_DATA_ADDR);
+ }
else
- printf("%s%u: %08"PRIx64"\n", name, i, ((uint64_t *) regs)[i]);
+ {
+ printf("%s%u: %016"PRIx64, name, i, ((uint64_t *) regs)[i]);
+ if ( reg_is_addr_mask[i] )
+ print_symbol(reg_is_addr_mask[i] & ((uint64_t *) regs)[i],
+ KERNEL_DATA_ADDR);
+ }
+ printf("\n");
}
}
@@ -368,8 +382,8 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
printf(" gs: %04x\n", regs->gs);
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 4);
- print_special(ctx->debugreg, "dr", 0xcf, 4);
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 4);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 4);
}
}
@@ -397,8 +411,8 @@ static void print_ctx_32on64(vcpu_guest_context_x86_64_t *ctx)
printf(" gs: %04x\n", regs->gs);
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 4);
- print_special(ctx->debugreg, "dr", 0xcf, 4);
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 4);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 4);
}
}
@@ -436,13 +450,21 @@ static void print_ctx_64(vcpu_guest_context_x86_64_t *ctx)
printf(" ds: %04x\t", regs->ds);
printf(" es: %04x\n", regs->es);
- printf(" fs: %04x @ %016"PRIx64"\n", regs->fs, ctx->fs_base);
- printf(" gs: %04x @ %016"PRIx64"/%016"PRIx64"\n", regs->gs,
+ printf(" fs: %04x @ %016"PRIx64, regs->fs, ctx->fs_base);
+ print_symbol(ctx->fs_base, KERNEL_DATA_ADDR);
+ printf("\n");
+ printf(" gs: %04x @ %016"PRIx64"/%016"PRIx64, regs->gs,
ctx->gs_base_kernel, ctx->gs_base_user);
+ if (symbol_table) {
+ print_symbol(ctx->gs_base_kernel, KERNEL_DATA_ADDR);
+ printf("/");
+ print_symbol(ctx->gs_base_user, KERNEL_DATA_ADDR);
+ }
+ printf("\n");
if (xenctx.disp_all) {
- print_special(ctx->ctrlreg, "cr", 0x1d, 8);
- print_special(ctx->debugreg, "dr", 0xcf, 8);
+ print_special(ctx->ctrlreg, "cr", 0x1d, cr_reg_mask, 8);
+ print_special(ctx->debugreg, "dr", 0xcf, dr_reg_mask, 8);
}
}
--
1.7.11.7
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v7 13/17] xenctx: Add convert of more registers to symbols
2014-03-21 17:43 ` [PATCH v7 " Don Slutz
@ 2014-03-24 10:51 ` Ian Campbell
0 siblings, 0 replies; 77+ messages in thread
From: Ian Campbell @ 2014-03-24 10:51 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, xen-devel, Ian Jackson, Jan Beulich, Stefano Stabellini
On Fri, 2014-03-21 at 13:43 -0400, Don Slutz wrote:
> hopefully not line wrapped
Sorry, but it was.
I recommend git send-email --in-reply-to='<message-id>' --reroll-count=7
for these cases, which will thread it and hopefully be clear enough what
it is without the precursor "here is v7 with X changed" since you will
have incorporated that into the patch's changelog.
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH v6 13/17] xenctx: Add convert of more registers to symbols
2014-03-21 14:11 ` [PATCH v6 " Don Slutz
2014-03-21 14:45 ` Jan Beulich
@ 2014-03-21 15:03 ` Ian Campbell
2014-03-21 17:38 ` Don Slutz
1 sibling, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 15:03 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, xen-devel, Ian Jackson, Jan Beulich, Stefano Stabellini
On Fri, 2014-03-21 at 10:11 -0400, Don Slutz wrote:
> On 03/21/14 08:34, Don Slutz wrote:
> > On 03/21/14 06:24, Jan Beulich wrote:
> >>
> >
> > Looks like they can.
> >
> >> Also, using C99 (available as gcc extension) here may make this
> >> a bit more legible:
> >>
> >> static const uint64_t cr_reg_mask[5] = { [2] = ~UINT64_C(0) };
> >> static const uint64_t dr_reg_mask[8] = { [0 ... 3] = ~UINT64_C(0) };
> >
> > Will test that it works on CentOS 5.10 and a send a v6 of just this.
> >
> > -Don Slutz
> >
> >> Jan
> >>
> >
>
> Here is v6:
It's whitespace knackered I'm afraid.
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v6 13/17] xenctx: Add convert of more registers to symbols
2014-03-21 15:03 ` [PATCH v6 " Ian Campbell
@ 2014-03-21 17:38 ` Don Slutz
0 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-21 17:38 UTC (permalink / raw)
To: Ian Campbell
Cc: Stefano Stabellini, George Dunlap, Ian Jackson, Don Slutz,
xen-devel, Jan Beulich
On 03/21/14 11:03, Ian Campbell wrote:
> On Fri, 2014-03-21 at 10:11 -0400, Don Slutz wrote:
>> On 03/21/14 08:34, Don Slutz wrote:
>>> On 03/21/14 06:24, Jan Beulich wrote:
>>> Looks like they can.
>>>
>>>> Also, using C99 (available as gcc extension) here may make this
>>>> a bit more legible:
>>>>
>>>> static const uint64_t cr_reg_mask[5] = { [2] = ~UINT64_C(0) };
>>>> static const uint64_t dr_reg_mask[8] = { [0 ... 3] = ~UINT64_C(0) };
>>> Will test that it works on CentOS 5.10 and a send a v6 of just this.
>>>
>>> -Don Slutz
>>>
>>>> Jan
>>>>
>> Here is v6:
> It's whitespace knackered I'm afraid.
>
>
Yup, thunderbird strikes again (or why I normally post patches via
git-send-email).
-Don Slutz
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH v5 13/17] xenctx: Add convert of more registers to symbols
2014-03-20 19:07 ` [PATCH v5 13/17] xenctx: Add convert of more registers to symbols Don Slutz
2014-03-21 10:24 ` Jan Beulich
@ 2014-03-21 15:07 ` Ian Campbell
2014-03-21 15:11 ` Jan Beulich
1 sibling, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 15:07 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, Stefano Stabellini, Ian Jackson, Jan Beulich, xen-devel
On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
> @@ -368,8 +380,11 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
> printf(" gs: %04x\n", regs->gs);
>
> if (xenctx.disp_all) {
> - print_special(ctx->ctrlreg, "cr", 0x1d, 4);
> - print_special(ctx->debugreg, "dr", 0xcf, 4);
> + uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
> + uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
Are you really using 8*64 bits to represent 8 boolean values? Your masks
are all 0 or ~0.
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 13/17] xenctx: Add convert of more registers to symbols
2014-03-21 15:07 ` [PATCH v5 " Ian Campbell
@ 2014-03-21 15:11 ` Jan Beulich
2014-03-21 16:06 ` Ian Campbell
0 siblings, 1 reply; 77+ messages in thread
From: Jan Beulich @ 2014-03-21 15:11 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: George Dunlap, xen-devel, Ian Jackson, Stefano Stabellini
>>> On 21.03.14 at 16:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
>
>> @@ -368,8 +380,11 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
>> printf(" gs: %04x\n", regs->gs);
>>
>> if (xenctx.disp_all) {
>> - print_special(ctx->ctrlreg, "cr", 0x1d, 4);
>> - print_special(ctx->debugreg, "dr", 0xcf, 4);
>> + uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
>> + uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
>
> Are you really using 8*64 bits to represent 8 boolean values? Your masks
> are all 0 or ~0.
Actually I had asked for this, since special registers may happen to have
(often at their bottom or top) bits not being part of an address.
Jan
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 13/17] xenctx: Add convert of more registers to symbols
2014-03-21 15:11 ` Jan Beulich
@ 2014-03-21 16:06 ` Ian Campbell
2014-03-21 18:16 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 16:06 UTC (permalink / raw)
To: Jan Beulich
Cc: George Dunlap, xen-devel, Ian Jackson, Don Slutz, Stefano Stabellini
On Fri, 2014-03-21 at 15:11 +0000, Jan Beulich wrote:
> >>> On 21.03.14 at 16:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
> >
> >> @@ -368,8 +380,11 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
> >> printf(" gs: %04x\n", regs->gs);
> >>
> >> if (xenctx.disp_all) {
> >> - print_special(ctx->ctrlreg, "cr", 0x1d, 4);
> >> - print_special(ctx->debugreg, "dr", 0xcf, 4);
> >> + uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
> >> + uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
> >
> > Are you really using 8*64 bits to represent 8 boolean values? Your masks
> > are all 0 or ~0.
>
> Actually I had asked for this, since special registers may happen to have
> (often at their bottom or top) bits not being part of an address.
I thought that might be the case, but I couldn't find any actual
printing of such a register.
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 13/17] xenctx: Add convert of more registers to symbols
2014-03-21 16:06 ` Ian Campbell
@ 2014-03-21 18:16 ` Don Slutz
2014-03-24 10:49 ` Ian Campbell
0 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-21 18:16 UTC (permalink / raw)
To: Ian Campbell
Cc: Stefano Stabellini, George Dunlap, Ian Jackson, Don Slutz,
xen-devel, Jan Beulich
On 03/21/14 12:06, Ian Campbell wrote:
> On Fri, 2014-03-21 at 15:11 +0000, Jan Beulich wrote:
>>>>> On 21.03.14 at 16:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
>>>
>>>> @@ -368,8 +380,11 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
>>>> printf(" gs: %04x\n", regs->gs);
>>>>
>>>> if (xenctx.disp_all) {
>>>> - print_special(ctx->ctrlreg, "cr", 0x1d, 4);
>>>> - print_special(ctx->debugreg, "dr", 0xcf, 4);
>>>> + uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
>>>> + uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
>>> Are you really using 8*64 bits to represent 8 boolean values? Your masks
>>> are all 0 or ~0.
>> Actually I had asked for this, since special registers may happen to have
>> (often at their bottom or top) bits not being part of an address.
> I thought that might be the case, but I couldn't find any actual
> printing of such a register.
>
> Ian.
>
Getting a kernel value there is not simple. Using a kdb + 2.6.18
kernel, I got:
rip: ffffffff8006bdd8 default_idle+0x29
flags: 00000246 i z p
rsp: ffffffff80467f90
rax: 0000000000000000 rcx: 0000000000000000 rdx: 0000000000000000
rbx: ffffffff8006bdaf rsi: 0000000000000001 rdi: ffffffff8031e738
rbp: 0000000000086800 r8: ffffffff80466000 r9: 000000000000003f
r10: ffff81003ffb4008 r11: 0000000000000246 r12: 0000000000000000
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cs: 0010 ss: 0018 ds: 0018 es: 0018
fs: 0000 @ 0000000000000000
gs: 0000 @ ffffffff80435000/0000000000000000 boot_cpu_pda/
cr0: 000000008005003b
cr2: 00002b1b311c0290
cr3: 0000000033692000
cr4: 00000000000006a0
dr0: ffffffff8006fb6d timer_interrupt+0x15
dr1: 0000000000000000
dr2: 0000000000000000
dr3: 0000000000000000
dr6: 00000000ffff0ff0
dr7: 0000000000000400
Code (instr addr ffffffff8006bdd8)
65 48 8b 04 25 10 00 00 00 8b 80 38 e0 ff ff a8 08 75 04 fb f4 <eb> 01
fb 65 48 8b 04 25 10 00 00
Stack:
ffffffff8004958f 0000000000200800 ffffffff80471809 0000000000086800
0000000000000000 ffffffff804c0740 ffffffff8047122f 80008e000010019c
00000000ffffffff 0000000000000000 0000000000000000 0000000000200000
0000000000000000 0000000000000000
Call Trace:
[<ffffffff8006bdd8>] default_idle+0x29 <--
[<ffffffff8004958f>] cpu_idle+0x95
[<ffffffff80471809>] start_kernel+0x220
[<ffffffff8047122f>] x86_64_start_kernel+0x22f
After leaving kdb and the hardware breakpoint disabled.
-Don Slutz
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 13/17] xenctx: Add convert of more registers to symbols
2014-03-21 18:16 ` Don Slutz
@ 2014-03-24 10:49 ` Ian Campbell
2014-03-24 14:09 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-24 10:49 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, xen-devel, Ian Jackson, Jan Beulich, Stefano Stabellini
On Fri, 2014-03-21 at 14:16 -0400, Don Slutz wrote:
> On 03/21/14 12:06, Ian Campbell wrote:
> > On Fri, 2014-03-21 at 15:11 +0000, Jan Beulich wrote:
> >>>>> On 21.03.14 at 16:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >>> On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
> >>>
> >>>> @@ -368,8 +380,11 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
> >>>> printf(" gs: %04x\n", regs->gs);
> >>>>
> >>>> if (xenctx.disp_all) {
> >>>> - print_special(ctx->ctrlreg, "cr", 0x1d, 4);
> >>>> - print_special(ctx->debugreg, "dr", 0xcf, 4);
> >>>> + uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
> >>>> + uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
> >>> Are you really using 8*64 bits to represent 8 boolean values? Your masks
> >>> are all 0 or ~0.
> >> Actually I had asked for this, since special registers may happen to have
> >> (often at their bottom or top) bits not being part of an address.
> > I thought that might be the case, but I couldn't find any actual
> > printing of such a register.
> >
> > Ian.
> >
>
> Getting a kernel value there is not simple. Using a kdb + 2.6.18
> kernel, I got:
I'm afraid I cannot follow what this has to do with the previous
exchange.
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 13/17] xenctx: Add convert of more registers to symbols
2014-03-24 10:49 ` Ian Campbell
@ 2014-03-24 14:09 ` Don Slutz
2014-03-27 16:06 ` Ian Campbell
0 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-24 14:09 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: George Dunlap, xen-devel, Ian Jackson, Jan Beulich, Stefano Stabellini
On 03/24/14 06:49, Ian Campbell wrote:
> On Fri, 2014-03-21 at 14:16 -0400, Don Slutz wrote:
>> On 03/21/14 12:06, Ian Campbell wrote:
>>> On Fri, 2014-03-21 at 15:11 +0000, Jan Beulich wrote:
>>>>>>> On 21.03.14 at 16:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>>>> On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
>>>>>
>>>>>> @@ -368,8 +380,11 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
>>>>>> printf(" gs: %04x\n", regs->gs);
>>>>>>
>>>>>> if (xenctx.disp_all) {
>>>>>> - print_special(ctx->ctrlreg, "cr", 0x1d, 4);
>>>>>> - print_special(ctx->debugreg, "dr", 0xcf, 4);
>>>>>> + uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
>>>>>> + uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
>>>>> Are you really using 8*64 bits to represent 8 boolean values? Your masks
>>>>> are all 0 or ~0.
>>>> Actually I had asked for this, since special registers may happen to have
>>>> (often at their bottom or top) bits not being part of an address.
>>> I thought that might be the case, but I couldn't find any actual
>>> printing of such a register.
>>>
>>> Ian.
>>>
>> Getting a kernel value there is not simple. Using a kdb + 2.6.18
>> kernel, I got:
> I'm afraid I cannot follow what this has to do with the previous
> exchange.
>
> Ian.
>
Re-reading it, I see that you may have been referring to some
register that is not cr0, cr2, cr3, cr4, dr0, dr1, dr2, dr3, dr6, and
dr7.
If that is the case, my reply does not make sense. However CR3
is an example. Intel and AMD say:
Bits 51:40 of CR3 are reserved and must be 0 (intel).
All CR3 bits are writable, except for unimplemented physical address
bits, which must be cleared to 0 (AMD).
PCD
Page-level Cache Disable (bit 4 of CR3) —
PWT Page-level Write-Through (bit 3 of CR3) —
So CR3 looks to be a register of the type in question. How ever, since it has a
physical address and the map file is all virtual addresses, I used a 0 so a false
match would not happen.
Let me know if more is needed.
-Don Slutz
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 13/17] xenctx: Add convert of more registers to symbols
2014-03-24 14:09 ` Don Slutz
@ 2014-03-27 16:06 ` Ian Campbell
2014-03-27 16:52 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-27 16:06 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, xen-devel, Ian Jackson, Jan Beulich, Stefano Stabellini
On Mon, 2014-03-24 at 10:09 -0400, Don Slutz wrote:
> On 03/24/14 06:49, Ian Campbell wrote:
> > On Fri, 2014-03-21 at 14:16 -0400, Don Slutz wrote:
> >> On 03/21/14 12:06, Ian Campbell wrote:
> >>> On Fri, 2014-03-21 at 15:11 +0000, Jan Beulich wrote:
> >>>>>>> On 21.03.14 at 16:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >>>>> On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
> >>>>>
> >>>>>> @@ -368,8 +380,11 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
> >>>>>> printf(" gs: %04x\n", regs->gs);
> >>>>>>
> >>>>>> if (xenctx.disp_all) {
> >>>>>> - print_special(ctx->ctrlreg, "cr", 0x1d, 4);
> >>>>>> - print_special(ctx->debugreg, "dr", 0xcf, 4);
> >>>>>> + uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
> >>>>>> + uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
> >>>>> Are you really using 8*64 bits to represent 8 boolean values? Your masks
> >>>>> are all 0 or ~0.
> >>>> Actually I had asked for this, since special registers may happen to have
> >>>> (often at their bottom or top) bits not being part of an address.
> >>> I thought that might be the case, but I couldn't find any actual
> >>> printing of such a register.
> >>>
> >>> Ian.
> >>>
> >> Getting a kernel value there is not simple. Using a kdb + 2.6.18
> >> kernel, I got:
> > I'm afraid I cannot follow what this has to do with the previous
> > exchange.
> >
> > Ian.
> >
>
> Re-reading it, I see that you may have been referring to some
> register that is not cr0, cr2, cr3, cr4, dr0, dr1, dr2, dr3, dr6, and
> dr7.
I was saying that I could not find a call to print_special where all
members of reg_is_addr_mask were not either 0 or ~0ULL and then you
starting talking about kdb + 2.6.18 kernels.
Have I missed a call to print_special with a mask value of something
other than 0 or ~0ULL somewhere in this patch or perhaps a subsequent
patch?
If I haven't missed it because it doesn't actually exist then
reg_is_addr_mask could be replaced by a bitmask, or maybe the
theoretical possibility of printing out a special register which does
need masking makes it worthwhile to keep this functionality, or maybe it
should be put aside until a patch which adds the printing of such a
register.
[...]
> So CR3 looks to be a register of the type in question. How ever, since it has a
> physical address and the map file is all virtual addresses, I used a 0 so a false
> match would not happen.
So in the end there are no special registers which have a symbol printed
and which have any bits to mask?
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 13/17] xenctx: Add convert of more registers to symbols
2014-03-27 16:06 ` Ian Campbell
@ 2014-03-27 16:52 ` Don Slutz
0 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-27 16:52 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: George Dunlap, xen-devel, Ian Jackson, Jan Beulich, Stefano Stabellini
On 03/27/14 12:06, Ian Campbell wrote:
> On Mon, 2014-03-24 at 10:09 -0400, Don Slutz wrote:
>> On 03/24/14 06:49, Ian Campbell wrote:
>>> On Fri, 2014-03-21 at 14:16 -0400, Don Slutz wrote:
>>>> On 03/21/14 12:06, Ian Campbell wrote:
>>>>> On Fri, 2014-03-21 at 15:11 +0000, Jan Beulich wrote:
>>>>>>>>> On 21.03.14 at 16:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>>>>>> On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
>>>>>>>
>>>>>>>> @@ -368,8 +380,11 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
>>>>>>>> printf(" gs: %04x\n", regs->gs);
>>>>>>>>
>>>>>>>> if (xenctx.disp_all) {
>>>>>>>> - print_special(ctx->ctrlreg, "cr", 0x1d, 4);
>>>>>>>> - print_special(ctx->debugreg, "dr", 0xcf, 4);
>>>>>>>> + uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
>>>>>>>> + uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
>>>>>>> Are you really using 8*64 bits to represent 8 boolean values? Your masks
>>>>>>> are all 0 or ~0.
>>>>>> Actually I had asked for this, since special registers may happen to have
>>>>>> (often at their bottom or top) bits not being part of an address.
>>>>> I thought that might be the case, but I couldn't find any actual
>>>>> printing of such a register.
>>>>>
>>>>> Ian.
>>>>>
>>>> Getting a kernel value there is not simple. Using a kdb + 2.6.18
>>>> kernel, I got:
>>> I'm afraid I cannot follow what this has to do with the previous
>>> exchange.
>>>
>>> Ian.
>>>
>> Re-reading it, I see that you may have been referring to some
>> register that is not cr0, cr2, cr3, cr4, dr0, dr1, dr2, dr3, dr6, and
>> dr7.
> I was saying that I could not find a call to print_special where all
> members of reg_is_addr_mask were not either 0 or ~0ULL and then you
> starting talking about kdb + 2.6.18 kernels.
I did get off track, sorry about that.
> Have I missed a call to print_special with a mask value of something
> other than 0 or ~0ULL somewhere in this patch or perhaps a subsequent
> patch?
Not that I know of.
> If I haven't missed it because it doesn't actually exist then
> reg_is_addr_mask could be replaced by a bitmask, or maybe the
> theoretical possibility of printing out a special register which does
> need masking makes it worthwhile to keep this functionality, or maybe it
> should be put aside until a patch which adds the printing of such a
> register.
>
> [...]
>> So CR3 looks to be a register of the type in question. How ever, since it has a
>> physical address and the map file is all virtual addresses, I used a 0 so a false
>> match would not happen.
> So in the end there are no special registers which have a symbol printed
> and which have any bits to mask?
Yes. I am happy to go either way. Since I am putting the finishing
comments on the next version (v8) of all these, for now I will continue
with Jan's requested way (mask values of 0 or ~0ULL ).
-Don Slutz
> Ian.
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH v5 14/17] xenctx: Add output of vcpu value and state for --all-vcpus
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (12 preceding siblings ...)
2014-03-20 19:07 ` [PATCH v5 13/17] xenctx: Add convert of more registers to symbols Don Slutz
@ 2014-03-20 19:07 ` Don Slutz
2014-03-27 16:07 ` Ian Campbell
2014-03-20 19:07 ` [PATCH v5 15/17] xenctx: Fix handling of !guest_protected_mode Don Slutz
` (3 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:07 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Ian Jackson,
Don Slutz, Jan Beulich
This makes it easier to know which vcpu the registers belong to and
when not all vcpus are online, which vcpu it is.
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
v5: Change vcpu=3 to vcpu3. Drop online.
tools/xentrace/xenctx.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index 5dfa7e6..2041928 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -1032,7 +1032,13 @@ static void dump_all_vcpus(void)
if ( xc_vcpu_getinfo(xenctx.xc_handle, xenctx.domid, vcpu, &vinfo) )
continue;
if ( vinfo.online )
+ {
+ printf("vcpu%d:\n", vcpu);
dump_ctx(vcpu);
+ printf("\n");
+ } else {
+ printf("vcpu%d offline\n\n", vcpu);
+ }
}
}
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* [PATCH v5 15/17] xenctx: Fix handling of !guest_protected_mode
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (13 preceding siblings ...)
2014-03-20 19:07 ` [PATCH v5 14/17] xenctx: Add output of vcpu value and state for --all-vcpus Don Slutz
@ 2014-03-20 19:07 ` Don Slutz
2014-03-21 15:09 ` Ian Campbell
2014-03-20 19:07 ` [PATCH v5 16/17] xenctx: Allow output for offline vcpu when specified Don Slutz
` (2 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:07 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Ian Jackson,
Don Slutz, Jan Beulich
This includes that the stack pointer is valid.
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
tools/xentrace/xenctx.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index 2041928..e7ef09b 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -498,8 +498,13 @@ static guest_word_t instr_pointer(vcpu_guest_context_any_t *ctx)
r += ctx->x32.user_regs.cs << NONPROT_MODE_SEGMENT_SHIFT;
}
else
+ {
r = ctx->x64.user_regs.rip;
+ if ( !guest_protected_mode )
+ r += ctx->x64.user_regs.cs << NONPROT_MODE_SEGMENT_SHIFT;
+ }
+
return r;
}
@@ -514,8 +519,13 @@ static guest_word_t stack_pointer(vcpu_guest_context_any_t *ctx)
r += ctx->x32.user_regs.ss << NONPROT_MODE_SEGMENT_SHIFT;
}
else
+ {
r = ctx->x64.user_regs.rsp;
+ if ( !guest_protected_mode )
+ r += ctx->x64.user_regs.ss << NONPROT_MODE_SEGMENT_SHIFT;
+ }
+
return r;
}
@@ -851,6 +861,9 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width, guest
return -1;
}
+ if ( !guest_protected_mode )
+ return 0;
+
if(xenctx.stack_trace)
printf("Stack Trace:\n");
else
@@ -1016,7 +1029,8 @@ static void dump_ctx(int vcpu)
#ifndef NO_TRANSLATION
if (print_code(&ctx, vcpu))
return;
- if ( kernel_addr(instr_pointer(&ctx)) >= KERNEL_TEXT_ADDR )
+ if ( !guest_protected_mode ||
+ kernel_addr(instr_pointer(&ctx)) >= KERNEL_TEXT_ADDR )
if ( print_stack(&ctx, vcpu, guest_word_size,
stack_pointer(&ctx)) )
return;
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v5 15/17] xenctx: Fix handling of !guest_protected_mode
2014-03-20 19:07 ` [PATCH v5 15/17] xenctx: Fix handling of !guest_protected_mode Don Slutz
@ 2014-03-21 15:09 ` Ian Campbell
2014-03-24 22:35 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 15:09 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, Stefano Stabellini, Ian Jackson, Jan Beulich, xen-devel
On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
> @@ -851,6 +861,9 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width, guest
> return -1;
> }
>
> + if ( !guest_protected_mode )
> + return 0;
> +
> if(xenctx.stack_trace)
> printf("Stack Trace:\n");
> else
> @@ -1016,7 +1029,8 @@ static void dump_ctx(int vcpu)
> #ifndef NO_TRANSLATION
> if (print_code(&ctx, vcpu))
> return;
> - if ( kernel_addr(instr_pointer(&ctx)) >= KERNEL_TEXT_ADDR )
> + if ( !guest_protected_mode ||
Aren't this and the check in the previous hunk contradictory and/or
equivalent (I can't decide which)
> + kernel_addr(instr_pointer(&ctx)) >= KERNEL_TEXT_ADDR )
> if ( print_stack(&ctx, vcpu, guest_word_size,
> stack_pointer(&ctx)) )
> return;
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 15/17] xenctx: Fix handling of !guest_protected_mode
2014-03-21 15:09 ` Ian Campbell
@ 2014-03-24 22:35 ` Don Slutz
0 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-24 22:35 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: George Dunlap, Stefano Stabellini, Ian Jackson, Jan Beulich, xen-devel
On 03/21/14 11:09, Ian Campbell wrote:
> On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
>> @@ -851,6 +861,9 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width, guest
>> return -1;
>> }
>>
>> + if ( !guest_protected_mode )
>> + return 0;
>> +
>> if(xenctx.stack_trace)
>> printf("Stack Trace:\n");
>> else
>> @@ -1016,7 +1029,8 @@ static void dump_ctx(int vcpu)
>> #ifndef NO_TRANSLATION
>> if (print_code(&ctx, vcpu))
>> return;
>> - if ( kernel_addr(instr_pointer(&ctx)) >= KERNEL_TEXT_ADDR )
>> + if ( !guest_protected_mode ||
> Aren't this and the check in the previous hunk contradictory and/or
> equivalent (I can't decide which)
Nope. The check in the previous hung is to say that in !guest_protected_mode
(aka real mode or 16bit mode), skip Call or Stack trace.
This check is to say do the stack dump.
Here is the output you get:
xenctx -t 5
cs:eip: f000:0000f033
flags: 00000046 z p
ss:esp: e000:0000f85a
eax: 00000000 ebx: 00000000 ecx: 00006b62 edx: 00000000
esi: 0000e000 edi: 0000f8b8 ebp: 00000000
ds: e000 es: 0040 fs: 0000 gs: 0000
Code (instr addr 000ff033)
fc 8e d5 67 8b 67 f8 8e dd 66 ff d1 8e de 8e d6 66 8b 26 b0 f0 <66> 89 3e b0 f0 66 5e 66 5b 66 5e
Stack:
000ef85a: 00000000 0000f88a 00000000 00000001 00000000 00006bbd 00000040 00000040
000ef87a: 00000000 0000000e 00001ff0 0000d4cb 00000000 0000000e 00000000 00001ff0
000ef89a: 00000040 ffffffff 00008e26 00001100 00008e30 1fee0246 00000000 1f000000
000ef8ba: 00000084 bb660000 0003fefc 3c038a67 66087464 03fef8bb 6606eb00 03ff00bb
000ef8da: 00b86600 67000a00 b0038966 00b3ba00 baaa0fee 3cec00b2 ba0a75f0 83edb004
Since this is 16 bit mode, maybe the stack should be:
Stack:
ef85a: 0000 0000 f88a 0000 0000 0000 0001 0000 0000 0000 6bbd 0000 0040 0000 0040 0000
ef87a: 0000 0000 000e 0000 1ff0 0000 d4cb 0000 0000 0000 000e 0000 0000 0000 1ff0 0000
ef89a: 0040 0000 ffff ffff 8e26 0000 1100 0000 8e30 0000 0246 1fee 0000 0000 0000 1f00
ef8ba: 0084 0000 0000 bb66 fefc 0003 8a67 3c03 7464 6608 f8bb 03fe eb00 6606 00bb 03ff
ef8da: 6600 00b8 0a00 6700 8966 b003 ba00 00b3 0fee baaa 00b2 3cec 75f0 ba0a b004 83ed
-Don Slutz
>> + kernel_addr(instr_pointer(&ctx)) >= KERNEL_TEXT_ADDR )
>> if ( print_stack(&ctx, vcpu, guest_word_size,
>> stack_pointer(&ctx)) )
>> return;
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH v5 16/17] xenctx: Allow output for offline vcpu when specified.
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (14 preceding siblings ...)
2014-03-20 19:07 ` [PATCH v5 15/17] xenctx: Fix handling of !guest_protected_mode Don Slutz
@ 2014-03-20 19:07 ` Don Slutz
2014-03-21 15:11 ` Ian Campbell
2014-03-20 19:07 ` [PATCH v5 17/17] xenctx: Fixup options checking Don Slutz
2014-03-21 15:14 ` [PATCH v5 00/17] xenctx: Many changes Ian Campbell
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:07 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Ian Jackson,
Don Slutz, Jan Beulich
xc_domain_hvm_getcontext_partial() will fail to get data for an
offline cpu. Switch back to PV mode of calculating ctxt_word_size
and guest_word_size in the case.
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
tools/xentrace/xenctx.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index e7ef09b..d6e85ac 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -994,6 +994,11 @@ static void dump_ctx(int vcpu)
if (xc_domain_hvm_getcontext_partial(
xenctx.xc_handle, xenctx.domid, HVM_SAVE_CODE(CPU),
vcpu, &cpuctx, sizeof cpuctx) != 0) {
+ if ( errno == EBADSLT )
+ {
+ printf("Note: vcpu%d offline:\n\n", vcpu);
+ goto vcpu_off_line;
+ }
perror("xc_domain_hvm_getcontext_partial");
return;
}
@@ -1007,6 +1012,7 @@ static void dump_ctx(int vcpu)
ctxt_word_size = (strstr(xen_caps, "xen-3.0-x86_64")) ? 8 : 4;
} else {
unsigned int gw;
+ vcpu_off_line:
if ( !xc_domain_get_guest_width(xenctx.xc_handle, xenctx.domid, &gw) )
ctxt_word_size = guest_word_size = gw;
}
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v5 16/17] xenctx: Allow output for offline vcpu when specified.
2014-03-20 19:07 ` [PATCH v5 16/17] xenctx: Allow output for offline vcpu when specified Don Slutz
@ 2014-03-21 15:11 ` Ian Campbell
2014-03-24 13:20 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 15:11 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, Stefano Stabellini, Ian Jackson, Jan Beulich, xen-devel
On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
> xc_domain_hvm_getcontext_partial() will fail to get data for an
> offline cpu. Switch back to PV mode of calculating ctxt_word_size
> and guest_word_size in the case.
Does that provide sensible results? I wouldn't have thought so.
Why not just print nothing for that vcpu?
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH v5 16/17] xenctx: Allow output for offline vcpu when specified.
2014-03-21 15:11 ` Ian Campbell
@ 2014-03-24 13:20 ` Don Slutz
0 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-24 13:20 UTC (permalink / raw)
To: Ian Campbell
Cc: Stefano Stabellini, George Dunlap, Ian Jackson, Don Slutz,
xen-devel, Jan Beulich
On 03/21/14 11:11, Ian Campbell wrote:
> On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
>> xc_domain_hvm_getcontext_partial() will fail to get data for an
>> offline cpu. Switch back to PV mode of calculating ctxt_word_size
>> and guest_word_size in the case.
> Does that provide sensible results? I wouldn't have thought so.
It does display sensible results for the registers.
At boot time you get:
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 2 1
xc_vcpu_getcontext: No data available
But once a cpu is used you get correct data.
I found out that I add missed a change to xc_translate_foreign_address()
(also check for errno == EBADSLT) which is needed to do the correct
virtual to physical address conversion. Will be part of this patch in the
next version. Here is some output using this new version.
Before "echo 0 > /sys/devices/system/cpu/cpu1/online":
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 1 1
rip: ffffffff810387db native_safe_halt+0xb
flags: 00000246 i z p
rsp: ffff88003e417ed8
rax: 0000000000000000 rcx: 0000000000000000 rdx: 0000000000000000
rbx: 0000000000000001 rsi: 0000000000000001 rdi: ffffffff81ddc228
rbp: ffff88003e417ed8 r8: 0000000000000000 r9: 0000000000000000
r10: 0000001bdca0ef03 r11: ffff88003e417e78 r12: ffffffff81c03800
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cs: 0010 ss: 0018 ds: 0018 es: 0018
fs: 0000 @ 0000000000000000
gs: 0000 @ ffff88000b420000/0000000000000000/
Code (instr addr ffffffff810387db)
44 00 00 fb c9 c3 0f 1f 40 00 55 48 89 e5 0f 1f 44 00 00 fb f4 <c9> c3 0f 1f 00 55 48 89 e5 0f 1f
Stack:
ffff88003e417ef8 ffffffff810149cd ffff88003e417fd8 ffffffff81c03800
ffff88003e417f28 ffffffff81009e06 ffff88003e417f18 a0460d871075161c
0000000000000000 0000000000000000 ffff88003e417f48 ffffffff814f6e1f
0000000000000000 00000001814f6bf5 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call Trace:
[<ffffffff810387db>] native_safe_halt+0xb <--
[<ffffffff810149cd>] default_idle+0x4d
[<ffffffff81009e06>] cpu_idle+0xb6
[<ffffffff814f6e1f>] start_secondary+0x22a
After "echo 0 > /sys/devices/system/cpu/cpu1/online":
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 1 1
Note: vcpu1 offline:
rip: ffffffff8102acc1 native_play_dead+0x51
flags: 00000006 nz p
rsp: ffff88003e417ee8
rax: ffff88000b420000 rcx: 0000000000000020 rdx: ffff88000b420000
rbx: 0000000000016500 rsi: 0000000000000086 rdi: 0000000000000005
rbp: ffff88003e417ef8 r8: 0000000000000000 r9: ffff88000b4315a8
r10: 0000000000000005 r11: 0000000000000000 r12: 0000000000016500
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cs: 0010 ss: 0018 ds: 0018 es: 0018
fs: 0000 @ 0000000000000000
gs: 0000 @ ffff88000b420000/0000000000000000/
Code (instr addr ffffffff8102acc1)
00 00 42 80 3c 20 03 76 0b 0f 09 0f 1f 44 00 00 0f 1f 40 00 f4 <eb> fd 48 8d 3c 18 e8 04 92 fe ff
Stack:
ffff88003e417fd8 ffffffff81c03800 ffff88003e417f28 ffffffff81009e4b
ffff88003e417f18 a0460d871075161c 0000000000000000 0000000000000000
ffff88003e417f48 ffffffff814f6e1f 0000000000000000 00000001814f6bf5
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call Trace:
[<ffffffff8102acc1>] native_play_dead+0x51 <--
[<ffffffff81009e4b>] cpu_idle+0xfb
[<ffffffff814f6e1f>] start_secondary+0x22a
Using offline.ko module (posted on the list, with the change to output
routine addresses) gives me on domU's serial console:
[ 393.119432] offline 1.1 who=0x1 wait=0 cpu=1 depth=0 count=100
[ 393.132654] init_module=ffffffffa0058210 offline_self=ffffffffa0058070 fill_stack=ffffffffa00580d0
[ 393.158013] offline done who=0x1
Which is telling me that insmod is on cpu1, and we are offlineing cpu0:
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 1 0
Note: vcpu0 offline:
rip: ffffffffa0058093
flags: 00000097 s nz a p c
rsp: ffff88000b403f58
rax: 0000000000000000 rcx: ffffffff81a8f020 rdx: 0000000000000001
rbx: ffff88000b403f68 rsi: 0000000000000000 rdi: 0000000000000000
rbp: ffff88000b403f58 r8: ffff88000b431800 r9: 0000000000000001
r10: 0000000000000000 r11: 0000000000000000 r12: ffff88000b431800
r13: 0000000000000001 r14: ffff88003dea96c0 r15: 00000000ffffffff
cs: 0010 ss: 0018 ds: 0018 es: 0018
fs: 0000 @ 0000000000000000
gs: 0000 @ ffff88000b400000/0000000000000000/
Code (instr addr ffffffffa0058093)
e0 00 00 83 f8 1f 77 0d 8b 15 e8 48 00 00 0f a3 c2 73 02 fa f4 <c9> c3 66 66 2e 0f 1f 84 00 00 00
Since this kernel module is not part of kernel text, the stack display is skipped. So
Use the new feature -d to force it out:
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 1 0 -d 0xffff88000b403f58 -t -T
Note: vcpu0 offline:
Stack:
ffff88000b403f58: ffff88000b403f98 ffffffff810a87e9 ffff88000b403f68 ffff88000b403f68
ffff88000b403f78: ffff88000b403f98 ffff88003dea96c0 ffffffff81a8f020 0000000000000000
ffff88000b403f98: ffff88000b403fa8 ffffffff8102a8f7 ffff88003efd3d30 ffffffff8100bdb3
ffff88000b403fb8: ffff88003efd3d30 0000000000000000 0000000000000000 0000000000000000
ffff88000b403fd8: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call Trace:
ffff88000b403f60: [<ffffffff810a87e9>] generic_smp_call_function_single_interrupt+0xa9
ffff88000b403fa0: [<ffffffff8102a8f7>] smp_call_function_single_interrupt+0x27
ffff88000b403fb0: [<ffffffff8100bdb3>] call_function_single_interrupt+0x13
Which is exactly the Call Trace that it should have.
Here is the state of vcpu1:
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 1 1 -t -T
rip: ffffffff810387db native_safe_halt+0xb
flags: 00000246 i z p
rsp: ffff88003e417ed8
rax: 0000000000000000 rcx: 0000000000000000 rdx: 0000000000000000
rbx: 0000000000000001 rsi: 0000000000000001 rdi: ffffffff81ddc228
rbp: ffff88003e417ed8 r8: 0000000000000000 r9: 0000000000000000
r10: 0000000000000000 r11: 0000000000000000 r12: ffffffff81c03800
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cs: 0010 ss: 0018 ds: 0018 es: 0018
fs: 0000 @ 0000000000000000
gs: 0000 @ ffff88000b420000/0000000000000000/
Code (instr addr ffffffff810387db)
44 00 00 fb c9 c3 0f 1f 40 00 55 48 89 e5 0f 1f 44 00 00 fb f4 <c9> c3 0f 1f 00 55 48 89 e5 0f 1f
Stack:
ffff88003e417ed8: ffff88003e417ef8 ffffffff810149cd ffff88003e417fd8 ffffffff81c03800
ffff88003e417ef8: ffff88003e417f28 ffffffff81009e06 ffff88003e417f18 bd1aee47aad97866
ffff88003e417f18: 0000000000000000 0000000000000000 ffff88003e417f48 ffffffff814f6e1f
ffff88003e417f38: 0000000000000000 00000001814f6bf5 0000000000000000 0000000000000000
ffff88003e417f58: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call Trace:
[<ffffffff810387db>] native_safe_halt+0xb <--
ffff88003e417ee0: [<ffffffff810149cd>] default_idle+0x4d
ffff88003e417f00: [<ffffffff81009e06>] cpu_idle+0xb6
ffff88003e417f30: [<ffffffff814f6e1f>] start_secondary+0x22a
Using gdbsx to also look at this data:
[root@dcs-xen-54 ~]# gdbsx -c 1 64 1
===> Context for DOMID:1
--> VCPU:1
rip:ffffffff810387db rsp:ffff88003e417ed8 flags:0000000000000246
rax:0000000000000000 rbx:0000000000000001 rcx:0000000000000000
rdx:0000000000000000 rsi:0000000000000001 rdi:ffffffff81ddc228
r08:0000000000000000 r09:0000000000000000 r10:0000000000000000
r11:0000000000000000 r12:ffffffff81c03800 r13:0000000000000000
r14:0000000000000000 r15:0000000000000000 rbp:ffff88003e417ed8
cs:0000000000000010 ds:0000000000000018 fs:0000000000000000 gs:0000000000000000
Call Trace:
[ffffffff810387db]
[ffffffff810149cd]
[ffffffff81c03800]
[ffffffff81009e06]
[ffffffff814f6e1f]
[ffffffff81a991e0]
[ffffffff8107f5f0]
[ffffffff81136a99]
[ffffffff81136a99]
[ffffffff81125b31]
[ffffffff81136a99]
[root@dcs-xen-54 ~]# gdbsx -c 1 64 0
===> Context for DOMID:1
--> VCPU:0
rip:ffffffffa0058093 rsp:ffff88000b403f58 flags:0000000000000097
rax:0000000000000000 rbx:ffff88000b403f68 rcx:ffffffff81a8f020
rdx:0000000000000001 rsi:0000000000000000 rdi:0000000000000000
r08:ffff88000b431800 r09:0000000000000001 r10:0000000000000000
r11:0000000000000000 r12:ffff88000b431800 r13:0000000000000001
r14:ffff88003dea96c0 r15:00000000ffffffff rbp:ffff88000b403f58
cs:0000000000000010 ds:0000000000000018 fs:0000000000000000 gs:0000000000000000
Call Trace:
[ffffffffa0058093]
[ffffffff810a87e9]
[ffffffff81a8f020]
[ffffffff8102a8f7]
[ffffffff8100bdb3]
[ffffffffffffffff]
[ffffffffffffffff]
[ffffffffffffffff]
[ffffffffffffffff]
[ffffffffffffffff]
[ffffffffffffffff]
(gdb) disass/r 0xffffffffa0058070,0xffffffffa0058097
Dump of assembler code from 0xffffffffa0058070 to 0xffffffffa0058097:
0xffffffffa0058070: 55 push %rbp
0xffffffffa0058071: 48 89 e5 mov %rsp,%rbp
0xffffffffa0058074: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
0xffffffffa0058079: 65 8b 04 25 b8 e0 00 00 mov %gs:0xe0b8,%eax
0xffffffffa0058081: 83 f8 1f cmp $0x1f,%eax
0xffffffffa0058084: 77 0d ja 0xffffffffa0058093
0xffffffffa0058086: 8b 15 e8 48 00 00 mov 0x48e8(%rip),%edx # 0xffffffffa005c974
0xffffffffa005808c: 0f a3 c2 bt %eax,%edx
0xffffffffa005808f: 73 02 jae 0xffffffffa0058093
0xffffffffa0058091: fa cli
0xffffffffa0058092: f4 hlt
=> 0xffffffffa0058093: c9 leaveq
0xffffffffa0058094: c3 retq
0xffffffffa0058095: 66 66 2e 0f 1f 84 00 00 00 00 00 data32 nopw %cs:0x0(%rax,%rax,1)
End of assembler dump.
> Why not just print nothing for that vcpu?
That is what "-C" does.
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH v5 17/17] xenctx: Fixup options checking.
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (15 preceding siblings ...)
2014-03-20 19:07 ` [PATCH v5 16/17] xenctx: Allow output for offline vcpu when specified Don Slutz
@ 2014-03-20 19:07 ` Don Slutz
2014-03-21 15:13 ` Ian Campbell
2014-03-21 15:14 ` [PATCH v5 00/17] xenctx: Many changes Ian Campbell
17 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-20 19:07 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, George Dunlap, Ian Jackson,
Don Slutz, Jan Beulich
Also display the correct program name in all cases.
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
tools/xentrace/xenctx.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index d6e85ac..164a13d 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -1110,6 +1110,7 @@ int main(int argc, char **argv)
{
int ch;
int ret;
+ char *prog = argv[0];
#ifndef NO_TRANSLATION
static const char *sopts = "fs:hak:SCn:b:l:DtTm:d:";
#else
@@ -1176,7 +1177,7 @@ int main(int argc, char **argv)
{
fprintf(stderr,
"%s: Unsupported value for --bytes-per-line. Needs to be 4 <= <bytes> <= %d\n",
- argv[0], MAX_BYTES_PER_LINE);
+ prog, MAX_BYTES_PER_LINE);
exit(-1);
}
break;
@@ -1190,7 +1191,7 @@ int main(int argc, char **argv)
{
fprintf(stderr,
"%s: Unsupported value for --lines. Needs to be >= 0\n",
- argv[0]);
+ prog);
exit(-1);
}
break;
@@ -1218,7 +1219,7 @@ int main(int argc, char **argv)
usage();
exit(-1);
case '?':
- fprintf(stderr, "%s --help for more options\n", argv[0]);
+ fprintf(stderr, "%s --help for more options\n", prog);
exit(-1);
}
}
@@ -1235,7 +1236,7 @@ int main(int argc, char **argv)
{
fprintf(stderr,
"%s both --frame-pointers and --dump-as-stack is not supported\n",
- argv[0]);
+ prog);
exit(-1);
}
#endif
@@ -1246,8 +1247,17 @@ int main(int argc, char **argv)
exit(-1);
}
- if (argc == 2)
+ if ( argc == 2 )
+ {
+ if ( xenctx.all_vcpus )
+ {
+ fprintf(stderr,
+ "%s both --all-vcpus and [VCPU] is not supported\n",
+ prog);
+ exit(-1);
+ }
vcpu = atoi(argv[1]);
+ }
if (symbol_table)
read_symbol_table(symbol_table);
--
1.8.4
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: [PATCH v5 17/17] xenctx: Fixup options checking.
2014-03-20 19:07 ` [PATCH v5 17/17] xenctx: Fixup options checking Don Slutz
@ 2014-03-21 15:13 ` Ian Campbell
2014-03-24 14:26 ` Don Slutz
0 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 15:13 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, Stefano Stabellini, Ian Jackson, Jan Beulich, xen-devel
On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
> Also display the correct program name in all cases.
Where was it wrong?
> Signed-off-by: Don Slutz <dslutz@verizon.com>
> ---
> tools/xentrace/xenctx.c | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
> index d6e85ac..164a13d 100644
> --- a/tools/xentrace/xenctx.c
> +++ b/tools/xentrace/xenctx.c
> @@ -1110,6 +1110,7 @@ int main(int argc, char **argv)
> {
> int ch;
> int ret;
> + char *prog = argv[0];
const?
> #ifndef NO_TRANSLATION
> static const char *sopts = "fs:hak:SCn:b:l:DtTm:d:";
> #else
> @@ -1176,7 +1177,7 @@ int main(int argc, char **argv)
> {
> fprintf(stderr,
> "%s: Unsupported value for --bytes-per-line. Needs to be 4 <= <bytes> <= %d\n",
> - argv[0], MAX_BYTES_PER_LINE);
> + prog, MAX_BYTES_PER_LINE);
> exit(-1);
> }
> break;
> @@ -1190,7 +1191,7 @@ int main(int argc, char **argv)
> {
> fprintf(stderr,
> "%s: Unsupported value for --lines. Needs to be >= 0\n",
> - argv[0]);
> + prog);
> exit(-1);
> }
> break;
> @@ -1218,7 +1219,7 @@ int main(int argc, char **argv)
> usage();
> exit(-1);
> case '?':
> - fprintf(stderr, "%s --help for more options\n", argv[0]);
> + fprintf(stderr, "%s --help for more options\n", prog);
> exit(-1);
> }
> }
> @@ -1235,7 +1236,7 @@ int main(int argc, char **argv)
> {
> fprintf(stderr,
> "%s both --frame-pointers and --dump-as-stack is not supported\n",
> - argv[0]);
> + prog);
> exit(-1);
> }
> #endif
> @@ -1246,8 +1247,17 @@ int main(int argc, char **argv)
> exit(-1);
> }
>
> - if (argc == 2)
> + if ( argc == 2 )
> + {
> + if ( xenctx.all_vcpus )
> + {
> + fprintf(stderr,
> + "%s both --all-vcpus and [VCPU] is not supported\n",
> + prog);
> + exit(-1);
> + }
> vcpu = atoi(argv[1]);
> + }
>
> if (symbol_table)
> read_symbol_table(symbol_table);
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 17/17] xenctx: Fixup options checking.
2014-03-21 15:13 ` Ian Campbell
@ 2014-03-24 14:26 ` Don Slutz
2014-03-27 16:10 ` Ian Campbell
0 siblings, 1 reply; 77+ messages in thread
From: Don Slutz @ 2014-03-24 14:26 UTC (permalink / raw)
To: Ian Campbell, Don Slutz
Cc: George Dunlap, Stefano Stabellini, Ian Jackson, Jan Beulich, xen-devel
On 03/21/14 11:13, Ian Campbell wrote:
> On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
>> Also display the correct program name in all cases.
> Where was it wrong?
After:
argv += optind; argc -= optind;
and so
#11's new error message is wrong.
Will adjust this patch to be before #11.
>> Signed-off-by: Don Slutz <dslutz@verizon.com>
>> ---
>> tools/xentrace/xenctx.c | 20 +++++++++++++++-----
>> 1 file changed, 15 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
>> index d6e85ac..164a13d 100644
>> --- a/tools/xentrace/xenctx.c
>> +++ b/tools/xentrace/xenctx.c
>> @@ -1110,6 +1110,7 @@ int main(int argc, char **argv)
>> {
>> int ch;
>> int ret;
>> + char *prog = argv[0];
> const?
Will add.
-Don Slutz
>
>> #ifndef NO_TRANSLATION
>> static const char *sopts = "fs:hak:SCn:b:l:DtTm:d:";
>> #else
>> @@ -1176,7 +1177,7 @@ int main(int argc, char **argv)
>> {
>> fprintf(stderr,
>> "%s: Unsupported value for --bytes-per-line. Needs to be 4 <= <bytes> <= %d\n",
>> - argv[0], MAX_BYTES_PER_LINE);
>> + prog, MAX_BYTES_PER_LINE);
>> exit(-1);
>> }
>> break;
>> @@ -1190,7 +1191,7 @@ int main(int argc, char **argv)
>> {
>> fprintf(stderr,
>> "%s: Unsupported value for --lines. Needs to be >= 0\n",
>> - argv[0]);
>> + prog);
>> exit(-1);
>> }
>> break;
>> @@ -1218,7 +1219,7 @@ int main(int argc, char **argv)
>> usage();
>> exit(-1);
>> case '?':
>> - fprintf(stderr, "%s --help for more options\n", argv[0]);
>> + fprintf(stderr, "%s --help for more options\n", prog);
>> exit(-1);
>> }
>> }
>> @@ -1235,7 +1236,7 @@ int main(int argc, char **argv)
>> {
>> fprintf(stderr,
>> "%s both --frame-pointers and --dump-as-stack is not supported\n",
>> - argv[0]);
>> + prog);
>> exit(-1);
>> }
>> #endif
>> @@ -1246,8 +1247,17 @@ int main(int argc, char **argv)
>> exit(-1);
>> }
>>
>> - if (argc == 2)
>> + if ( argc == 2 )
>> + {
>> + if ( xenctx.all_vcpus )
>> + {
>> + fprintf(stderr,
>> + "%s both --all-vcpus and [VCPU] is not supported\n",
>> + prog);
>> + exit(-1);
>> + }
>> vcpu = atoi(argv[1]);
>> + }
>>
>> if (symbol_table)
>> read_symbol_table(symbol_table);
>
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 17/17] xenctx: Fixup options checking.
2014-03-24 14:26 ` Don Slutz
@ 2014-03-27 16:10 ` Ian Campbell
0 siblings, 0 replies; 77+ messages in thread
From: Ian Campbell @ 2014-03-27 16:10 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, Stefano Stabellini, Ian Jackson, Jan Beulich, xen-devel
On Mon, 2014-03-24 at 10:26 -0400, Don Slutz wrote:
> On 03/21/14 11:13, Ian Campbell wrote:
> > On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
> >> Also display the correct program name in all cases.
> > Where was it wrong?
>
> After:
>
> argv += optind; argc -= optind;
>
> and so
I see. Please say something like "since we adjust argv during option
parsing take a copy of the original argv[0]" in the commit message.
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH v5 00/17] xenctx: Many changes.
2014-03-20 19:06 [PATCH v5 00/17] xenctx: Many changes Don Slutz
` (16 preceding siblings ...)
2014-03-20 19:07 ` [PATCH v5 17/17] xenctx: Fixup options checking Don Slutz
@ 2014-03-21 15:14 ` Ian Campbell
2014-03-21 17:37 ` Don Slutz
17 siblings, 1 reply; 77+ messages in thread
From: Ian Campbell @ 2014-03-21 15:14 UTC (permalink / raw)
To: Don Slutz
Cc: George Dunlap, Stefano Stabellini, Ian Jackson, Jan Beulich, xen-devel
On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
> Add more functionality to xenctx.
So, I've been through this and it mostly seems independently useful, but
the overriding thought I've been having is: aren't you piecemeal
reinventing the debugger (like gdbsx)?
Ian.
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: [PATCH v5 00/17] xenctx: Many changes.
2014-03-21 15:14 ` [PATCH v5 00/17] xenctx: Many changes Ian Campbell
@ 2014-03-21 17:37 ` Don Slutz
0 siblings, 0 replies; 77+ messages in thread
From: Don Slutz @ 2014-03-21 17:37 UTC (permalink / raw)
To: Ian Campbell
Cc: Stefano Stabellini, George Dunlap, Ian Jackson, Don Slutz,
xen-devel, Jan Beulich
On 03/21/14 11:14, Ian Campbell wrote:
> On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote:
>> Add more functionality to xenctx.
> So, I've been through this and it mostly seems independently useful, but
> the overriding thought I've been having is: aren't you piecemeal
> reinventing the debugger (like gdbsx)?
Sort of. If this were a new command, I would think that "reinventing
the debugger" would be more important.
There are several issues with using gdbsx to get a quick look at a domU:
1) you need to start gdbsx & gdb
2) gdb does not simply take a System.map file, nor is vmlinuz a big help.
There is most likely a way to get gdb to use a System.map but I do not
currently remember it.
3) Getting a call trace in gdb is hard without debugging symbols. And
last I
knew there was no native command to format it like xenctx:
Call Trace:
[<ffffffff8006bdd8>] default_idle+0x29 <--
[<ffffffff8004958f>] cpu_idle+0x95
[<ffffffff80471809>] start_kernel+0x220
[<ffffffff8047122f>] x86_64_start_kernel+0x22f
4) You need to remember if this domU is in 32 or 64 bit mode (looks like
saying 64, for a 32 may be ok).
5) Older gdb's do not display the registers that xenctx does.
The main new features would be -d and -m. The rest are enhancements or
fixes.
Hope this helps.
-Don Slutz
> Ian.
>
^ permalink raw reply [flat|nested] 77+ messages in thread