From: Don Slutz <dslutz@verizon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Don Slutz <dslutz@verizon.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Jan Beulich <jbeulich@suse.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH v8 13/20] xenctx: change is_kernel_text() into kernel_addr().
Date: Tue, 01 Apr 2014 17:33:23 -0400 [thread overview]
Message-ID: <533B30A3.80808@terremark.com> (raw)
In-Reply-To: <1396361415.8667.199.camel@kazak.uk.xensource.com>
On 04/01/14 10:10, Ian Campbell wrote:
> On Thu, 2014-03-27 at 15:05 -0400, Don Slutz wrote:
>> A new enum has been added to allow the caller to determine if this
>> kernel address is a text, data, or module address. This can help
>> understand what is going on.
>>
>> Kernel modules are only found when they are more then 1MiB after
> s/then/than/
>
> But where does this magic assumption come from? Where does 1MiB come
> from?
I just picked it. I did base it on the theory that a given routine
should not be too large. I do feel that any routine that has more
then 1MiB of code bytes is too large.
>> kernel_end or the symbol "__brk_limit". The symbol "vgettimeofday"
>> is used to mark the end of where modules can be loaded.
> I can just about see from the vmlinux.lds.S why __brk_limit might be
> somewhat relevant, but where does the use of vgettimeofday come from?
>
> The 3.2 kernel on my desktop doesn't list vgettimeofday in System.map
> for example and in any case you can't rely on it not being moved around.
> (you can't really rely on __brk_limit either, but it seems less likely
> to move).
I would guess you are running a 32 bit desktop.
> (TBH, I'd suggest that this new functionality be left out for now, this
> series has gone on for long enough as it is)
I will drop the module stuff. (basically back to v5).
>
>> ffff88003b759dc0: [<ffffffffa005f19d>]
>> ffff88003b759e50: [<ffffffffa005f1e8>]
>> ffff88003b759ee0: [<ffffffffa005f1e8>]
>> ffff88003b759f70: [<ffffffffa005f1e8>]
>>
>> This shows that a kernel module is using a lot of stack.
> Does it? All I see is the four additional entries at the base, consuming
> about 0.5k which I suppose is a lot. I suppose those are stack frames
> corresponding to some module? Perhaps mark them as such with "unknown
> module function"?
Here is maybe a better output:
dcs-xen-54:~/xen>sudo tools/xentrace/xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 3 1 -n 3
rip: ffffffff81346898 io_serial_out+0x18
flags: 00000002 nz
rsp: ffff880032bb1308
rax: 0000000000000074 rcx: 0000000000000000 rdx: 00000000000003f8
rbx: ffffffff81ff8f00 rsi: 0000000000000000 rdi: ffffffff81ff8f00
rbp: ffff880032bb1308 r8: ffffffff81c03a10 r9: 0000000000000080
r10: 0000000000000004 r11: 0000000000000000 r12: 0000000000000074
r13: 0000000000000064 r14: 000000000000001b r15: ffffffff81346f20
cs: 0010 ss: 0018 ds: 0000 es: 0000
fs: 0000 @ 00007f41d1061700
gs: 0000 @ ffff88000b420000/0000000000000000/
Code (instr addr ffffffff81346898)
e5 0f 1f 44 00 00 0f b6 4f 41 89 d0 0f b7 57 08 d3 e6 01 f2 ee <c9> c3 66 0f 1f 44 00 00 55 48 89
Stack:
ffff880032bb1328 ffffffff81346f51 ffffffff81e361c1 ffffffff81ff8f00
ffff880032bb1368 ffffffff813428de ffffffff8100bc0e 0000000000000000
ffffffff81ff8f00 0000000000000001 0000000000000064 ffffffff81e361a7
ffff880032bb13b8 ffffffff813472ad 0000000032bb14f8 0000000000000006
ffff880032bb1428 ffffffff81affa00 ffffffff81c03800 000000000000e707
Call Trace:
[<ffffffff81346898>] io_serial_out+0x18 <--
ffff880032bb1310: [<ffffffff81346f51>] serial8250_console_putchar+0x31
ffff880032bb1330: [<ffffffff813428de>] uart_console_write+0x3e
ffff880032bb1338: [<ffffffff8100bc0e>] apic_timer_interrupt+0xe
ffff880032bb1370: [<ffffffff813472ad>] serial8250_console_write+0xbd
ffff880032bb13c0: [<ffffffff8106b8f5>] __call_console_drivers+0x75
ffff880032bb13f0: [<ffffffff8106b95a>] _call_console_drivers+0x4a
ffff880032bb1410: [<ffffffff8106be6e>] release_console_sem+0x4e
ffff880032bb1450: [<ffffffff8106c628>] vprintk+0x248
ffff880032bb14f0: [<ffffffff814fd363>] printk+0x41
ffff880032bb1550: [<ffffffffa005119d>]
ffff880032bb15e0: [<ffffffffa00511e8>]
ffff880032bb1670: [<ffffffffa00511e8>]
ffff880032bb1700: [<ffffffffa00511e8>]
ffff880032bb1790: [<ffffffffa00511e8>]
ffff880032bb1820: [<ffffffffa00511e8>]
ffff880032bb18b0: [<ffffffffa00511e8>]
ffff880032bb1940: [<ffffffffa00511e8>]
ffff880032bb19d0: [<ffffffffa00511e8>]
ffff880032bb1a60: [<ffffffffa00511e8>]
ffff880032bb1af0: [<ffffffffa00511e8>]
ffff880032bb1b80: [<ffffffffa00511e8>]
ffff880032bb1c10: [<ffffffffa00511e8>]
ffff880032bb1ca0: [<ffffffffa00511e8>]
ffff880032bb1d30: [<ffffffffa00511e8>]
ffff880032bb1dc0: [<ffffffffa00511e8>]
ffff880032bb1e50: [<ffffffffa00511e8>]
ffff880032bb1ee0: [<ffffffffa00511e8>]
ffff880032bb1f70: [<ffffffffa00511e8>]
ffff880032bb2000: [<ffffffffa00511e8>]
ffff880032bb2090: [<ffffffffa00511e8>]
ffff880032bb2120: [<ffffffffa00511e8>]
ffff880032bb21b0: [<ffffffffa00511e8>]
ffff880032bb2240: [<ffffffffa00511e8>]
ffff880032bb22d0: [<ffffffffa00511e8>]
ffff880032bb2360: [<ffffffffa00511e8>]
ffff880032bb23f0: [<ffffffffa00511e8>]
ffff880032bb2480: [<ffffffffa00511e8>]
ffff880032bb2510: [<ffffffffa00511e8>]
ffff880032bb25a0: [<ffffffffa00511e8>]
ffff880032bb2630: [<ffffffffa00511e8>]
ffff880032bb26c0: [<ffffffffa00511e8>]
ffff880032bb2750: [<ffffffffa00511e8>]
ffff880032bb27e0: [<ffffffffa00511e8>]
ffff880032bb2870: [<ffffffffa00511e8>]
ffff880032bb2900: [<ffffffffa00511e8>]
ffff880032bb2990: [<ffffffffa00511e8>]
ffff880032bb2a20: [<ffffffffa00511e8>]
ffff880032bb2ab0: [<ffffffffa00511e8>]
ffff880032bb2b40: [<ffffffffa00511e8>]
ffff880032bb2bd0: [<ffffffffa00511e8>]
ffff880032bb2c60: [<ffffffffa00511e8>]
ffff880032bb2cf0: [<ffffffffa00511e8>]
ffff880032bb2d80: [<ffffffffa00511e8>]
ffff880032bb2e10: [<ffffffffa00511e8>]
ffff880032bb2ea0: [<ffffffffa00511e8>]
ffff880032bb2f30: [<ffffffffa00511e8>]
ffff880032bb2fc0: [<ffffffffa00511e8>]
ffff880032bb3050: [<ffffffffa00511e8>]
ffff880032bb30e0: [<ffffffffa00511e8>]
ffff880032bb3170: [<ffffffffa00511e8>]
ffff880032bb3200: [<ffffffffa00511e8>]
ffff880032bb3290: [<ffffffffa00511e8>]
ffff880032bb3320: [<ffffffffa00511e8>]
ffff880032bb33b0: [<ffffffffa00511e8>]
ffff880032bb3440: [<ffffffffa00511e8>]
ffff880032bb34d0: [<ffffffffa00511e8>]
ffff880032bb3560: [<ffffffffa00511e8>]
ffff880032bb35f0: [<ffffffffa00511e8>]
ffff880032bb3680: [<ffffffffa00511e8>]
ffff880032bb3710: [<ffffffffa00511e8>]
ffff880032bb37a0: [<ffffffffa00511e8>]
ffff880032bb3830: [<ffffffffa00511e8>]
ffff880032bb38c0: [<ffffffffa00511e8>]
ffff880032bb3950: [<ffffffffa00511e8>]
ffff880032bb39e0: [<ffffffffa00511e8>]
ffff880032bb3a70: [<ffffffffa00511e8>]
ffff880032bb3b00: [<ffffffffa00511e8>]
ffff880032bb3b90: [<ffffffffa00511e8>]
ffff880032bb3c20: [<ffffffffa00511e8>]
ffff880032bb3cb0: [<ffffffffa00511e8>]
ffff880032bb3d40: [<ffffffffa00511e8>]
ffff880032bb3dd0: [<ffffffffa00511e8>]
ffff880032bb3e60: [<ffffffffa00511e8>]
ffff880032bb3ee0: [<ffffffffa0051210>]
ffff880032bb3ef0: [<ffffffffa0051241>]
ffff880032bb3f20: [<ffffffff8100204c>] do_one_initcall+0x3c
ffff880032bb3f30: [<ffffffffa0055740>]
ffff880032bb3f50: [<ffffffff810b0eb1>] sys_init_module+0xe1
ffff880032bb3f80: [<ffffffff8100b0f2>] system_call_fastpath+0x16
dcs-xen-54:~/xen>
I could, but that looks to be a task for later.
>> Signed-off-by: Don Slutz <dslutz@verizon.com>
>> ---
>> v8:
>> Added more to commit message.
>> Added some basic linux kernel module reporting.
>> Moved kernel_end into define tree in case no symbol found.
> kernel_start is overridable on the command line, so kernel_end probably
> should be too.
Ok, but at this time I think I will defer adding "kernel_end command
option" to later.
In old 32bit linux virtual addresses were split at kernel start. Kernel end
was the same as end of memory. With 64bit linux adding vsyscall32
(/proc/sys/abi/vsyscall32) These are no longer kernel addresses.
>> At some point __bss_stop was added and _end was dropped. Both
>> mean end of named kernel data.
> Hrm I suppose we already encode a bunch of Linux kernel specific symbols
> in this tool so a couple more don't hurt.
>
>>
[...]
>> + return KERNEL_TEXT_ADDR;
>> + if ( xenctx.kernel_start_set )
>> + {
>> + if ( addr >= kernel_start )
> Has this logic changed since last time? Why no check of kernel_end?
No. No check because the user requested a particular split.
> Previously we only used kernel_start if no symbol table was provided.
> That seemed logical enough to me, is there a reason to change that?
>
This is what to do when both are specified. What I went with is that
if both are specified and we know this is a kernel symbol, then say so.
if the user said anything above KADDR is a kernel address, also accept
that.
Here is output of the same 3 stack pages in use guest that is paused:
dcs-xen-54:~/xen>sudo tools/xentrace/xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 3 1 -n 3 -k 0xffffffff80000000
rip: ffffffff81346898 io_serial_out+0x18
flags: 00000002 nz
rsp: ffff880032bb1308
rax: 0000000000000074 rcx: 0000000000000000 rdx: 00000000000003f8
rbx: ffffffff81ff8f00 rsi: 0000000000000000 rdi: ffffffff81ff8f00
rbp: ffff880032bb1308 r8: ffffffff81c03a10 r9: 0000000000000080
r10: 0000000000000004 r11: 0000000000000000 r12: 0000000000000074
r13: 0000000000000064 r14: 000000000000001b r15: ffffffff81346f20
cs: 0010 ss: 0018 ds: 0000 es: 0000
fs: 0000 @ 00007f41d1061700
gs: 0000 @ ffff88000b420000/0000000000000000/
Code (instr addr ffffffff81346898)
e5 0f 1f 44 00 00 0f b6 4f 41 89 d0 0f b7 57 08 d3 e6 01 f2 ee <c9> c3 66 0f 1f 44 00 00 55 48 89
Stack:
ffff880032bb1328 ffffffff81346f51 ffffffff81e361c1 ffffffff81ff8f00
ffff880032bb1368 ffffffff813428de ffffffff8100bc0e 0000000000000000
ffffffff81ff8f00 0000000000000001 0000000000000064 ffffffff81e361a7
ffff880032bb13b8 ffffffff813472ad 0000000032bb14f8 0000000000000006
ffff880032bb1428 ffffffff81affa00 ffffffff81c03800 000000000000e707
Call Trace:
[<ffffffff81346898>] io_serial_out+0x18 <--
ffff880032bb1310: [<ffffffff81346f51>] serial8250_console_putchar+0x31
ffff880032bb1318: [<ffffffff81e361c1>] __log_buf+0xe721
ffff880032bb1320: [<ffffffff81ff8f00>] serial8250_ports
ffff880032bb1330: [<ffffffff813428de>] uart_console_write+0x3e
ffff880032bb1338: [<ffffffff8100bc0e>] apic_timer_interrupt+0xe
ffff880032bb1348: [<ffffffff81ff8f00>] serial8250_ports
ffff880032bb1360: [<ffffffff81e361a7>] __log_buf+0xe707
ffff880032bb1370: [<ffffffff813472ad>] serial8250_console_write+0xbd
ffff880032bb1390: [<ffffffff81affa00>] serial8250_console
ffff880032bb1398: [<ffffffff81c03800>] cpu_online_bits
ffff880032bb13c0: [<ffffffff8106b8f5>] __call_console_drivers+0x75
ffff880032bb13d0: [<ffffffff81e2797c>] logbuf_lock
ffff880032bb13f0: [<ffffffff8106b95a>] _call_console_drivers+0x4a
ffff880032bb1410: [<ffffffff8106be6e>] release_console_sem+0x4e
ffff880032bb1428: [<ffffffff81ea7b24>] printk_buf+0x64
ffff880032bb1450: [<ffffffff8106c628>] vprintk+0x248
ffff880032bb14a8: [<ffffffff81c03a10>] cpu_present_bits+0x10
ffff880032bb14f0: [<ffffffff814fd363>] printk+0x41
ffff880032bb1538: [<ffffffff81c03a10>] cpu_present_bits+0x10
ffff880032bb1550: [<ffffffffa005119d>] __brk_limit+0x1e01c19d
ffff880032bb15e0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1670: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1700: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1790: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1820: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb18b0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1940: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb19d0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1a60: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1af0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1b80: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1c10: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1ca0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1d30: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1dc0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1e50: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1ee0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1f70: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2000: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2090: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2120: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb21b0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2240: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb22d0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2360: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb23f0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2480: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2510: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb25a0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2630: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb26c0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2750: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb27e0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2870: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2900: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2990: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2a20: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2ab0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2b40: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2bd0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2c60: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2cf0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2d80: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2e10: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2ea0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2f30: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2fc0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3050: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb30e0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3170: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3200: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3290: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3320: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb33b0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3440: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb34d0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3560: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb35f0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3680: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3710: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb37a0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3830: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb38c0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3950: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb39e0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3a70: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3b00: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3b90: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3c20: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3cb0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3d40: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3dd0: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3e60: [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3ee0: [<ffffffffa0051210>] __brk_limit+0x1e01c210
ffff880032bb3ef0: [<ffffffffa0051241>] __brk_limit+0x1e01c241
ffff880032bb3f20: [<ffffffff8100204c>] do_one_initcall+0x3c
ffff880032bb3f30: [<ffffffffa0055740>] __brk_limit+0x1e020740
ffff880032bb3f50: [<ffffffff810b0eb1>] sys_init_module+0xe1
ffff880032bb3f80: [<ffffffff8100b0f2>] system_call_fastpath+0x16
>> + return KERNEL_TEXT_ADDR;
>> + }
>> + else
>> + {
>> + if ( kernel_text &&
>> + (addr >= kernel_text &&
>> + addr <= kernel_end) )
>> + return KERNEL_DATA_ADDR;
>> + if ( kernel_mod_start &&
>> + (addr >= kernel_mod_start &&
>> + addr <= kernel_mod_end) )
>> + return KERNEL_MOD_ADDR;
>> + }
>> + return NOT_KERNEL_ADDR;
>> }
>>
>> @@ -180,7 +223,14 @@ static void print_symbol(guest_word_t addr)
>> if (addr==s->address)
>> printf(" %s", s->name);
>> else
>> - printf(" %s+%#x", s->name, (unsigned int)(addr - s->address));
>> + {
>> + unsigned long long offset = addr - s->address;
>> +
>> + if ( addr_type == KERNEL_MOD_ADDR &&
>> + offset > MAX_MOD_OFFSET )
>> + return;
> Shouldn't kernel_addr have not returned KERNEL_MOD_ADDR in that case?
>
I did. But that symbol may also be too far also:
Like this is:
ffff880032bb3950: [<ffffffffa08711e8>] offline::checkit+0x41c1e8
This was an attempt to allow a more complete map to be used.
Like a copy of /proc/kallsyms from the guest. This would add
lines like:
ffffffffa000a510 t rpc_destroy_wait_queue [sunrpc]
ffffffffa002d140 b rpciod_workqueue [sunrpc]
ffffffffa00128c0 t auth_domain_put [sunrpc]
ffffffffa002cd00 d __tracepoint_rpc_task_sleep [sunrpc]
ffffffffa002cd40 d __tracepoint_rpc_task_complete [sunrpc]
ffffffffa0017100 t xdr_shift_buf [sunrpc]
ffffffffa000c9e0 t rpcauth_register [sunrpc]
I.E doing this gives:
...
ffff880032bb3c20: [<ffffffffa00511e8>] init_module [offline]+0x1e8
ffff880032bb3cb0: [<ffffffffa00511e8>] init_module [offline]+0x1e8
ffff880032bb3d40: [<ffffffffa00511e8>] init_module [offline]+0x1e8
ffff880032bb3dd0: [<ffffffffa00511e8>] init_module [offline]+0x1e8
ffff880032bb3e60: [<ffffffffa00511e8>] init_module [offline]+0x1e8
ffff880032bb3ee0: [<ffffffffa0051210>] init_module [offline]+0x210
ffff880032bb3ef0: [<ffffffffa0051241>] init_module [offline]+0x241
ffff880032bb3f20: [<ffffffff8100204c>] do_one_initcall+0x3c
ffff880032bb3f30: [<ffffffffa0055740>] init_module [offline]+0x4740
ffff880032bb3f50: [<ffffffff810b0eb1>] sys_init_module+0xe1
ffff880032bb3f80: [<ffffffff8100b0f2>] system_call_fastpath+0x16
-Don Slutz
>> + printf(" %s+%#llx", s->name, offset);
>> + }
>> }
>>
>> static void read_symbol_table(const char *symtab)
> Ian.
>
next prev parent reply other threads:[~2014-04-01 21:33 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-27 19:05 [PATCH v8 00/20] xenctx: Many changes Don Slutz
2014-03-27 19:05 ` [PATCH v8 01/20] xenctx: clean up usage output Don Slutz
2014-03-27 19:05 ` [PATCH v8 02/20] xenctx: Clean up stack trace when hypercall_page not in symbol table Don Slutz
2014-03-27 19:05 ` [PATCH v8 03/20] xenctx: Add -n (--display-stack-pages) option to output larger stack Don Slutz
2014-04-01 13:19 ` Ian Campbell
2014-04-01 13:25 ` George Dunlap
2014-04-01 20:28 ` Don Slutz
2014-04-02 10:39 ` Ian Campbell
2014-03-27 19:05 ` [PATCH v8 04/20] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines) Don Slutz
2014-04-01 14:30 ` Ian Campbell
2014-03-27 19:05 ` [PATCH v8 05/20] xenctx: Add command line option -D (--decode-as-ascii) Don Slutz
2014-04-01 13:27 ` Ian Campbell
2014-03-27 19:05 ` [PATCH v8 06/20] xenctx: Add command line option -t (--tag-stack-dump) Don Slutz
2014-03-27 19:05 ` [PATCH v8 07/20] xenctx: Change print_symbol to do the space before Don Slutz
2014-03-27 19:05 ` [PATCH v8 08/20] xenctx: More info on failed to map page Don Slutz
2014-03-27 19:05 ` [PATCH v8 09/20] xenctx: Add output of stack address to Call and Stack Trace Don Slutz
2014-04-01 13:28 ` Ian Campbell
2014-03-27 19:05 ` [PATCH v8 10/20] xenctx: Add -m (--memory) <maddr> option to dump memory at maddr Don Slutz
2014-04-01 13:30 ` Ian Campbell
2014-03-27 19:05 ` [PATCH v8 11/20] xenctx: Add error output if --all-vcpus (-C) and [VCPU] are both specified Don Slutz
2014-04-01 13:44 ` Ian Campbell
2014-04-01 18:24 ` Don Slutz
2014-03-27 19:05 ` [PATCH v8 12/20] xenctx: Add -d (--dump-as-stack) <daddr> option to dump memory at daddr as a stack Don Slutz
2014-04-01 13:46 ` Ian Campbell
2014-04-01 18:23 ` Don Slutz
2014-03-27 19:05 ` [PATCH v8 13/20] xenctx: change is_kernel_text() into kernel_addr() Don Slutz
2014-04-01 14:10 ` Ian Campbell
2014-04-01 21:33 ` Don Slutz [this message]
2014-04-02 10:34 ` Ian Campbell
2014-04-02 17:08 ` Don Slutz
2014-03-27 19:05 ` [PATCH v8 14/20] xenctx: Add convert of more registers to symbols Don Slutz
2014-04-01 14:11 ` Ian Campbell
2014-04-01 17:25 ` Don Slutz
2014-03-27 19:05 ` [PATCH v8 15/20] xenctx: Add output of vcpu value and state for --all-vcpus Don Slutz
2014-03-27 19:05 ` [PATCH v8 16/20] xenctx: Fix handling of !guest_protected_mode Don Slutz
2014-04-01 14:14 ` Ian Campbell
2014-04-01 18:35 ` Don Slutz
2014-04-02 10:41 ` Ian Campbell
2014-03-27 19:05 ` [PATCH v8 17/20] xenctx: Allow output for offline vcpu when specified Don Slutz
2014-04-01 14:24 ` Ian Campbell
2014-04-01 19:24 ` Don Slutz
2014-04-02 10:42 ` Ian Campbell
2014-03-27 19:05 ` [PATCH v8 18/20] xenctx: Add 16 bit output Don Slutz
2014-04-01 14:25 ` Ian Campbell
2014-04-01 18:53 ` Don Slutz
2014-03-27 19:05 ` [PATCH v8 19/20] xenctx: Fix print_ctx_32on64's print_special call Don Slutz
2014-04-01 14:27 ` Ian Campbell
2014-03-27 19:05 ` [PATCH v8 20/20] xenctx: Ensure errno is not zero on error in xc_translate_foreign_address() Don Slutz
2014-04-01 14:30 ` Ian Campbell
2014-04-01 20:49 ` Don Slutz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=533B30A3.80808@terremark.com \
--to=dslutz@verizon.com \
--cc=Ian.Campbell@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).