Extension modules in C++
by Petr Tesarik
Hi all,
as part of SUSE HackWeek8, David started work on a GUI extension using Qt4,
which is a C++ project. One of the early annoyances is that an extension
module must include the declarations from defs.h, and we currently use some C
identifiers which happen to be keywords in C++, namely:
- struct namespace
- struct namespace namespace (in struct symbol_table_data)
- char *typename (in struct gnu_request)
Can I rename them? But you said earlier that the existing API must never
change... Any other suggestions to make this include file parseable by a C++
compiler?
TIA,
Petr Tesarik
SUSE Linux
12 years, 3 months
Re: [Crash-utility] Question about ARM module address range
by anderson＠prospeed.net
> Hi Dave
>
> I have taken a short look at modules_vaddr and module_end and I have both
> seen relevant data:
>
> crash> help -m
> modules_vaddr: bf000000
> modules_end: bfffffff
>
> and data similar to what you see. What I also have seen is that when
> modules are loaded then modules_vaddr and modules_end seems correct and
> when no modules have been loaded then strange values are presented. I have
> looked at too few examples to be certain that this is "always" true.
>
> I assume (not checked in source code) that no vmalloc area is allocated
> for modules if no modules are loaded. Then the function
> first_vmalloc_address() will return data which is stored in modules_vaddr
> but has nothing to do with this.
>
> So I think that the question is what values should modules_vaddr and
> modules_end have if no modules are loaded. Does it matter, except that it
> might be confusing for a user? Looking at arm.c where modules_vaddr and
> modules_end are used, I think the code will behaves correctly (by luck?!),
> also in the case of no modules.
>
> Jan
>
> Jan Karlsson
> Senior Software Engineer
> MIB
I don't have access to my sample ARM vmcores (on vacation), but none
of them have any modules loaded. So in those 3 cases, the vmalloc range
starts at either d0807000 or c6024000, and so the hardwired modules_end
is confusing. But it appears from your description that modules are put
in a their own virtual address region from bf00000 to bffffff, whereas
other vmalloc() calls generate virtual addresses above c000000?
(as shown by kmem -v). In that case, you're right, the code would
work as is. Anyway, it did confuse me a bit -- perhaps arm_cmd_mach()
should show different "KERNEL VMALLOC BASE" and "KERNEL MODULES BASE"
addresses, i.e., similar to x86_64?
Dave
Dave
12 years, 3 months
using crash for ARM
by paawan oza
Hi,
I would like to use crash utility on ARM.
what I understand is there might be two ways to go about it.
1) cross compile whole crash for arm itself, which doesnt seem to be good option because on arm target we will need lots of depedent packages.
2) run crash on x86 and have gdbserver/remoter server compiled on target. and have serial connection and so on..
please suggest instructions or any pointers regarding the same.
Regards,
Oza.
12 years, 3 months
ARM w/40-bit physical address space and ARM64
by Dave Anderson
Hi guys,
By any chance are you gents looking into updating the crash utility's
ARM support for its new 40-bit PAE capability, or the 64-bit ARM
architecture?
Dave
12 years, 3 months
Question about ARM module address range
by Dave Anderson
Hi guys,
While looking at the ARM per-cpu address range issue, I ran into
something re: the ARM module address range values that has me
confused.
In arm_init(), POST_VM, you've got:
machdep->machspec->modules_end = machdep->kvbase - 1;
But it never gets used, because here in arm_is_module_addr() the
local variable "module_end" is used instead -- although it is set
to the same value:
static int
arm_is_module_addr(ulong vaddr)
{
ulong modules_start;
ulong modules_end = machdep->kvbase - 1;
if (!MODULES_VADDR) {
/*
* In case we are still initializing, and vm_init() has not been
* called, we use defaults here which is 16MB below kernel start
* address.
*/
modules_start = machdep->kvbase - 16 * 1024 * 1024;
} else {
modules_start = MODULES_VADDR;
}
return (vaddr >= modules_start && vaddr <= modules_end);
}
and where MODULES_VADDR is #define'd as:
#define MODULES_VADDR (machdep->machspec->modules_vaddr)
So given that "modules_end" is set to "machdep->kvbase - 1", and given the
output from "help -m" on the 3 sample ARM dumps I have:
2.6.35:
crash> help -m
...
kvbase: c0000000
...
vmalloc_start_addr: d0000000
modules_vaddr: d0807000
modules_end: bfffffff
kernel_text_start: c0008000
...
2.6.36:
crash> help -m
...
kvbase: c0000000
...
vmalloc_start_addr: c5800000
modules_vaddr: c6024000
modules_end: bfffffff
kernel_text_start: c0008000
2.6.38:
crash> help -m
...
kvbase: c0000000
...
vmalloc_start_addr: d0000000
modules_vaddr: d0807000
modules_end: bfffffff
kernel_text_start: c0008000
...
So given that "modules_end" is always below the kvbase (bfffffff),
then arm_is_module_addr() will always return FALSE -- except maybe
during pre-vm_init() time when the range is temporarily set to
be the "default range" between bf000000 and bfffffff. (and would
there *ever* be a module in that range?)
Anyway, although I don't think it's a problem, given that the
only caller of arm_is_module_addr() is arm_is_vmalloc_addr(),
and that function will fall through and still return TRUE if
it is a module address.
But it just looks strange, and at least it would seem that:
(1) the machdep->machspec->modules_end version should be used, and
(2) it should be updated post-vm_init() so that the arm_is_module_addr()
function actually works?
Or am I missing something?
Dave
12 years, 4 months
Re: [Crash-utility] [PATCH] add support to "virsh dump-guest-memory"(qemu memory dump)
by anderson＠prospeed.net
> Hello Dave,
>
> I made this patch to make crash can analyze core dump file created by
> "virsh dump-guest-memory"(I will call it "qemu memory dump" below). In
> my test(guest OS: RHEL6.2 x86 & x86_64), the patch works well with dump
> files created by "qemu memory dump".
>
> However, after some investigation, I think I need to discuss further
> works with you.
>
> The core dump created by qemu memory dump is similar to kdump. The
> distinctness only focuses on note sections. The former one gets
> note sections with a name called "QEMU".
>
> 1. Some registers' information stored in "CORE" note sections, needed
> by crash, also stores in "QEMU" note sections. I think it's not
> reasonable to replace them. What do you think?
>
> 2. Other registers which are only stored in "QEMU" note sections are
> not directly used in crash. I will continue investigating the use of
> these registers. And if you give some suggestion, it will be helpful.
>
> --
> --
> Regards
> Qiao Nuohan
Qiao,
I'm sending this from my home email address -- I am going to be
on vacation for the next two weeks, and will have limited internet
access during that time. So I won't be able to look at this
patch in detail until the week of August 6th.
Anyway, one thing about the patch that I don't like is this
flags/flags2 usage:
#define NETDUMP_DUMPFILE() (pc->flags & (NETDUMP|REM_NETDUMP))
#define DISKDUMP_DUMPFILE() (pc->flags & DISKDUMP)
#define KDUMP_DUMPFILE() (pc->flags & KDUMP)
+#define QEMU_MEM_DUMP_DUMPFILE() ((pc->flags & NETDUMP) && (pc->flags2 &
QEMU_MEM_DUMP))
#define XENDUMP_DUMPFILE() (pc->flags & XENDUMP)
#define XEN_HYPER_MODE() (pc->flags & XEN_HYPER)
None of the other individual dumpfile types "share" a flag with
any other dumpfile type. And so having *both* the NETDUMP flag
*and* the QEMU_MEM_DUMP_DUMPFILE flags set at the same time makes
no sense. It's simply *not* a NETDUMP, and all of the locations
where you do something like this are needlessly confusing:
+ else if (pc->flags & NETDUMP) {
+ if (pc->flags2 & QEMU_MEM_DUMP)
+ retval = qemu_mem_dump_memory_dump(fp);
+ else
+ retval = netdump_memory_dump(fp);
+ }
It may have somehow made your patch easier, but please re-work it
such that QEMU_MEM_DUMP_DUMPFILE() only relies on a single flag bit.
Also, when I get back to work, perhaps you can also make a small sample
dumpfile available to me to test your patch with.
Thanks,
Dave Anderson
12 years, 4 months
ARM: crash registers might be read from the wrong physical address
by Karlsson, Jan
Hi Dave
I found a problem in arm.c that arm_get_crash_notes() is called too early. This has never been a problem until now.
arm_get_crash_notes() in arm.c
calls readmem(, KVADDR, )
which calls kvtop()
which calls machdep->kvtop that is arm_kvtop
which uses vt->vmalloc_start
vt->vmalloc_start is initialized in vm_init
>From main_loop:
machdep_init(POST_GDB);
vm_init();
machdep_init(POST_VM);
arm_get_crash_notes() is currently called in the POST_GDB section of machdep_init, but should be moved to the POST_VM section. I put the comment and the code just before:
if (init_unwind_tables()) {
and then it works fine. Without this fix the crash registers might be read from the wrong physical address.
Jan
Jan Karlsson
Senior Software Engineer
MIB
Sony Mobile Communications
Tel: +46703062174
sonymobile.com<http://sonymobile.com/>
[cid:image001.jpg@01CD64D5.0A61B6C0]
12 years, 4 months
[PATCH 0/5] crash: Small bundle of fixes for Xen
by Daniel Kiper
Hi,
It looks that Xen support for crash have not been maintained
since 2009. I am trying to fix this. Here it is small
bundle of fixes:
- xen: Always calculate max_cpus value,
- xen: Read only crash notes for onlined CPUs,
- x86/xen: Read variables from dynamically allocated per_cpu data,
- xen: Get idle data from alternative source,
- xen: Read data correctly from dynamically allocated console ring too.
Daniel
12 years, 4 months
Problem in runq command
by Karlsson, Jan
Hi Dave
I found a problem with the runq command in the function dump_CFS_runqueues in task.c. The problem is in:
if (!(rq_sp = per_cpu_symbol_search("per_cpu__runqueues")))
error(FATAL, "per-cpu runqueues does not exist\n");
as that code does not support single core systems. However the rest of the function seems to handle single core correctly, so by just adding one line:
if (!(rq_sp = per_cpu_symbol_search("per_cpu__runqueues")))
if (!(rq_sp = symbol_search("runqueues")))
error(FATAL, "per-cpu runqueues does not exist\n");
the runq command works as it should. Of course the text in the error message should also be updated to something more proper.
Jan
Jan Karlsson
Senior Software Engineer
MIB
Sony Mobile Communications
Tel: +46703062174
sonymobile.com<http://sonymobile.com/>
[cid:image001.jpg@01CD6006.CF9C2700]
12 years, 4 months
ptov command
by Karlsson, Jan
Hi Dave
I have a question about the ptov command. Ptov only handles kernel virtual addresses and their corresponding physical addresses. However if you give ptov a physical address that does not correspond to a kernel virtual address it still answers with an address. Users might get confused and do not know when to trust ptov, especially as the inverse command vtop always works.
So I would like to restrict ptov to give a result only when it is valid. The idea I have is that if ptov returns a valid virtual address then vtop on that address should give the same physical address back again. True??
cmd_ptov() in memory.c
....
vaddr = PTOV(paddr);
kvtop(0, vaddr, &paddr_tst, 0);
if (paddr != paddr_tst) ... invalid vaddr, do not print it ...
Any comments?
Jan
Jan Karlsson
Senior Software Engineer
MIB
Sony Mobile Communications
Tel: +46703062174
sonymobile.com<http://sonymobile.com/>
[cid:image001.jpg@01CD5AAD.EB8A3DC0]
12 years, 4 months
