On Fri, 25 Feb 2005 11:33:48 +0100 (CET), Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: > >One of my m68k configs has been giving > >| Inconsistent kallsyms data >| Try setting CONFIG_KALLSYMS_EXTRA_PASS > >since 2.6.11-rc3 or so. Setting CONFIG_KALLSYMS_EXTRA_PASS, or applying Keith >Owen's patch to fix an issue for SH >(http://seclists.org/lists/linux-kernel/2005/Jan/0017.html) doesn't help.
This is either a toolchain bug or an error in vmlinux.lds for m68k. Sections are overlapping in the .tmp_vmlinux files. Merging the output from objdump -h and nm into a single map and using type '0' as the start of a section clearly shows that .bss, .data.cacheline_aligned and .init.text are overlapping. .bss variables (types b and B) appear after the start of .data.cacheline_aligned, and even after the start of .init.text. kallsyms flags an error because some of the .bss variables are moving from .data.cacheline_aligned to .init.text between pass 1 and 2. That changes the set of KALLSYMS symbols between pass 1 and 2, which trips the verification bug. This is not a kallsyms bug, it is an m68k toolchain problem, kallsyms is just picking it up. Patch for generating this map is in a separate mail. 00189c30 0 .bss 00189c30 b inbuf 00189c30 B ROOT_DEV 00189c30 B system_state 00189c30 B Version_132619 00189c34 B saved_command_line 00189c34 b window 00189c38 b insize 00189c3c b inptr 00189c40 b outcnt 00189c44 b exit_code ... 0018e2bc b acqseq.2953 0018e2bc b dummy.2902 0018e2bc b xfrm_state_bydst 0018e2c0 0 .data.cacheline_aligned 0018e2c0 d acct_globals 0018e2c0 D tasklist_lock 0018e2f0 A _edata 0018e2f0 D tcp_hashinfo 0018e32c B xfrm_policy_list 0018e330 b netdev_chain 0018e334 b dev_boot_setup 0018e344 b xfrm_policy_afinfo 0018e3c4 b xfrm_dst_cache 0018e3c8 b xfrm_policy_gc_work 0018e424 b gifconf_list 0018e9f8 b log_start 0018e9fc b con_start 0018ea00 b log_end 0018ea04 b logged_chars 0018ea08 b console_cmdline 0018ea88 b console_may_schedule 0018f000 0 .init.text 0018f000 A __init_begin 0018f000 T _sinittext 0018f000 T __start 0018f98c t nosmp 0018f998 t maxcpus 0018f9b4 t obsolete_checksetup 0018fa48 t debug_kernel 0018fa62 t quiet_kernel 0018fa7c t unknown_bootoption 0018fcc8 t init_setup 0018fcea t do_early_param 0018fd50 T parse_early_param 0018fd98 T start_kernel 0018ff3c t initcall_debug_setup 0018ff48 t do_initcalls 0019000e t do_basic_setup 00190034 t load_ramdisk 00190056 t readonly 0019006e t readwrite 00190088 t try_name 0019021e T name_to_dev_t 001902bc b xfrm_state_byspi <==== 001904a8 t root_dev_setup 001904c6 t root_data_setup 001904d4 t fs_names_setup 001904e2 t root_delay_setup 00190500 t get_fs_names 0019057c t do_mount_root 0019060e T mount_block_root 00190702 T change_floppy 001907d6 T mount_root 0019082e T prepare_namespace 00190934 t prompt_ramdisk 00190956 t ramdisk_start_setup 00190974 t identify_ramdisk_image 00190b46 T rd_load_image 00190df2 T rd_load_disk 00190e9c t huft_build 00191284 t huft_free 001912a8 t inflate_codes 00191668 t inflate_stored 001917d4 t inflate_fixed 001918fc t inflate_dynamic 00191e00 t inflate_block 00191ee0 t inflate 00191f86 t makecrc 00192000 t gunzip 001922bc b xfrm_state_afinfo <==== 0019233c b xfrm_state_gc_work <==== 00192560 t malloc ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/