Re: [Crash-utility] Additional fix for per-cpu data symbol naming problem

----- "Ryota Ozaki" <ozaki.ryota(a)gmail.com&gt; wrote: > Hi, > > I tried crash 5.0.3 for linux 2.6.34 (x86_64) and faced the problem > about per-cpu data symbol naming, which is described in ChangeLog > as it's already fixed. I observed to fix the problem and found the > following fix for x86_64_verify_symbol() in x86_64.c helped me. > > I'm not sure whether the fix is correct or not, but it would be help for > correct fix. > > Thanks, >   ozaki-r > > > --- x86_64.c.orig       2010-05-19 12:26:11.000000000 +0000 > +++ x86_64.c    2010-05-19 08:23:30.000000000 +0000 > @@ -1974,7 +1974,7 @@ >                         if (STRNEQ(name, "per_cpu") || >                             STREQ(name, "__per_cpu_end")) >                                 return TRUE; > -                       if (type == 'V') > +                       if (type == 'V' || type == 'D' || type == 'd') >                                 return TRUE; >                 } Yes, I already have that same patch queued for the next release, which I hope to have ready today or tomorrow.

The fix in 5.0.3 was based upon my own builds of 2.6.34 kernels that introduced the new per-cpu symbol naming scheme.  But when I build x86_64 kernels, the per-cpu symbol types are type 'V'. For example, here's a 2.6.34-rc5 kernel that I built -- note there are few absolute ('a' or 'A') symbols after "__per_cpu_start", but all the "real" per-cpu symbols are type 'V': # strings vmlinux | grep "Linux version" Linux version 2.6.34-rc5 (root(a)intel-d3c4702-01.rhts.eng.bos.redhat.com) (gcc version 4.4.3 20100121 (Red Hat 4.4.3-1) (GCC) ) #1 SMP Fri Apr 30 18:20:16 EDT 2010 # nm -Bn vmlinux                 w __crc_softirq_work_list                 U do_hypervisor_callback 0000000000000000 a L3_PAGE_OFFSET 0000000000000000 A VDSO32_PRELINK 0000000000000000 D __per_cpu_start 0000000000000000 V irq_stack_union 0000000000000000 A xen_irq_disable_direct_reloc 0000000000000000 A xen_save_fl_direct_reloc 0000000000000040 A VDSO32_vsyscall_eh_frame_size 0000000000000100 a i 0000000000000100 a vector 0000000000000110 a L4_PAGE_OFFSET 00000000000001e7 A kexec_control_code_size 00000000000001f0 A VDSO32_NOTE_MASK 00000000000001fe a L3_START_KERNEL 00000000000001ff a L4_START_KERNEL 0000000000000400 A VDSO32_sigreturn 0000000000000410 A VDSO32_rt_sigreturn 0000000000000420 A VDSO32_vsyscall 0000000000000430 A VDSO32_SYSENTER_RETURN 0000000000004000 V gdt_page 0000000000005000 V exception_stacks 000000000000b000 V xen_vcpu 000000000000b020 V xen_vcpu_info 000000000000b060 V idt_desc 000000000000b070 V xen_cr0_value 000000000000b080 V xen_mc_irq_flags 000000000000b0a0 V mc_buffer 000000000000c5b0 V xen_cr3 000000000000c5b8 V xen_current_cr3 ... [ cut ] ... 0000000000016700 V cpu_tlbstate 0000000000016740 V runqueues 0000000000017100 V sched_clock_data 0000000000017140 V cfd_data 0000000000017180 V call_single_queue 00000000000171c0 V csd_data 00000000000171e8 D __per_cpu_end ... Although I still don't understand why it happens (compiler? CONFIG option?), a patch to continue recognizing 'd' and 'D' symbols is obviously needed.

Thanks,  Dave -- Crash-utility mailing list Crash-utility(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility