Re: Why module's global symbol cannot be displayed in crash? [ARM]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- Original Message -----
> 
> 
> ----- Original Message -----
> 
> > After your fix, the module could show module address now.
> > However I don't know whether this showing is correct or not...
> > For while I want to check the module's defined global variant like
> > below, I just find it is not being mapped yet...
> > But this variant definition is very straightforward, like:
> > int cctdev_major =   0;
> > 
> > 
> > crash> sym cctdev_major
> > bf16564d (B) cctdev_major
> > crash> vtop -k bf16564d
> > VIRTUAL   PHYSICAL
> > bf16564d  (not mapped)
> > 
> > PAGE DIRECTORY: c0004000
> >   PGD: c0006fc4 => 1f3cdc11
> >   PMD: c0006fc4 => 1f3cdc11
> >   PTE: 1f3cd594 => 0
> > 
> > I don't know what is going wrong there, and I am planning to manually
> > print out symbols' address before trigger the dump, and to see
> > whether they could be aligned.
> > 
> > Do you have some better idea how to fix it?...
> 
> No, not really, I'm not an ARM guy...
> 
> But it's possible/probable that the "vtop" translation on kernel module
> virtual (vmalloc) addresses may not be working correctly.  I also noted
> yesterday that "vtop" on user-space virtual addresses fails pretty miserably
> most of the time.  Both arm_kvtop() and arm_uvtop() both end up calling the
> common arm_vtop() function, so I'm guessing that it's the culprit.
> 
> Dave

FYI, I note you used "vtop -k" above, which I only noticed was required
yesterday when I got my first ARM modules.  To address that annoyance, I've
got this fix queued for crash-6.1.5:

 - Fix for the ARM "vtop" command when run on a module address.  Without
   the patch, the command fails with error message "vtop: ambiguous
   address: <module-address>  (requires -u or -k)".
   (anderson@xxxxxxxxxx)

--- arm.c	22 Feb 2013 14:22:38 -0000	1.20
+++ arm.c	20 Mar 2013 16:31:58 -0000	1.21
@@ -30,6 +30,7 @@
 static int arm_verify_symbol(const char *, ulong, char);
 static int arm_is_module_addr(ulong);
 static int arm_is_kvaddr(ulong);
+static int arm_is_uvaddr(ulong, struct task_context *);
 static int arm_in_exception_text(ulong);
 static int arm_in_ret_from_syscall(ulong, int *);
 static void arm_back_trace(struct bt_info *);
@@ -227,7 +228,7 @@
 	        machdep->kvbase = symbol_value("_stext") & 0xffff0000UL;
 		machdep->identity_map_base = machdep->kvbase;
 		machdep->is_kvaddr = arm_is_kvaddr;
-		machdep->is_uvaddr = generic_is_uvaddr;
+		machdep->is_uvaddr = arm_is_uvaddr;
 		machdep->eframe_search = arm_eframe_search;
 		machdep->back_trace = arm_back_trace_cmd;
 		machdep->processor_speed = arm_processor_speed;
@@ -388,8 +389,8 @@
 	fprintf(fp, "         dis_filter: arm_dis_filter()\n");
 	fprintf(fp, "           cmd_mach: arm_cmd_mach()\n");
 	fprintf(fp, "       get_smp_cpus: arm_get_smp_cpus()\n");
-	fprintf(fp, "          is_kvaddr: generic_is_kvaddr()\n");
-	fprintf(fp, "          is_uvaddr: generic_is_uvaddr()\n");
+	fprintf(fp, "          is_kvaddr: arm_is_kvaddr()\n");
+	fprintf(fp, "          is_uvaddr: arm_is_uvaddr()\n");
 	fprintf(fp, "       verify_paddr: generic_verify_paddr()\n");
 	fprintf(fp, "    show_interrupts: generic_show_interrupts()\n");
         fprintf(fp, "   get_irq_affinity: generic_get_irq_affinity()\n");
@@ -677,6 +678,15 @@
 	return (vaddr >= machdep->kvbase);
 }
 
+static int
+arm_is_uvaddr(ulong vaddr, struct task_context *unused)
+{
+	if (arm_is_module_addr(vaddr))
+		return FALSE;
+
+	return (vaddr < machdep->kvbase);
+}
+
 /*
  * Returns TRUE if given pc is in exception area.
  */

But obviously the fix above does not address the correctness
of the vtop operation itself.

Dave

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility


[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux