7:54 a.m.
----- "Ryota Ozaki" <ozaki.ryota(a)gmail.com> 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
8:14 a.m.
New subject: Additional fix for per-cpu data symbol naming problem
Hi Dave
Thanks for quick response.
On Wed, May 19, 2010 at 9:54 PM, Dave Anderson <anderson(a)redhat.com> wrote:
----- "Ryota Ozaki" <ozaki.ryota(a)gmail.com> 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.
Good news!
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.
Here is my output. Hope it would be your help.
# strings vmlinux | grep "Linux version"
Linux version 2.6.34-20100517.core (root@host103) (gcc version 4.1.2
20070925 (Red Hat 4.1.2-33)) #1 SMP Tue May 18 16:14:49 JST 2010
# nm -Bn vmlinux |grep -A 10 __per_cpu_start
0000000000000000 D __per_cpu_start
0000000000000000 D irq_stack_union
0000000000000040 A VDSO32_vsyscall_eh_frame_size
0000000000000110 a L4_PAGE_OFFSET
00000000000001e7 A kexec_control_code_size
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
# nm -Bn vmlinux |grep -B 10 __per_cpu_end
0000000000010da0 d ipv4_cookie_scratch
0000000000010f40 D init_tss
0000000000013200 D irq_stat
0000000000013240 D cpu_info
0000000000013300 D cpu_tlbstate
0000000000013340 d runqueues
0000000000013c80 d sched_clock_data
0000000000013cc0 d cfd_data
0000000000013d00 d call_single_queue
0000000000013d40 d csd_data
0000000000013d68 D __per_cpu_end
Thanks,
ozaki-r
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
5157
days inactive
5157
days old
devel@lists.crash-utility.osci.io
1 comments
2 participants
participants (2)
-
Dave Anderson -
Ryota Ozaki