Messages in this thread | | | From | Keith Owens <> | Subject | Re: Check for references to discarded sections during build time | Date | Tue, 07 Feb 2006 01:31:11 +1100 |
| |
On Sat, Feb 04, 2006 at 11:50:25PM +0100, Sam Ravnborg wrote: > Hi Keith. > > While doing some other modpost.c changes I thought about the > possibility to do the reference_init check during the modpost stage - so > it is done early and author can catch warning when he made the error. > Attached is first cut. > > It does a much more lousy job than reference_init because it identifies > the module and not the .o file. I hope to later identify the function > where the illegal reference hapens.
My main concern is that we cannot get the .o file with this approach, I am particulary concerned about this approach when processing vmlinux. Static function names are duplicated in the kernel. Reporting a dangling reference to init or discarded data by function name rather than by object will lead to confusion if the reference is from one of the duplicate function names.
# nm vmlinux | fgrep ' t ' | awk '{print $3}' | sort | uniq -dc
produces this horrible list of duplicate function names (IA64):
2 autofs_get_sb 2 base_probe 3 c_next 2 count 2 create_elf_tables 2 c_show 3 c_start 3 c_stop 3 default_handler 3 destroy_inodecache 2 dev_ifsioc 3 disable_slot 2 do_vfs_lock 4 dst_output 2 dump_seek 2 dump_write 2 elf_core_dump 3 enable_slot 2 error 3 exact_lock 3 exact_match 2 fill_note 2 fill_prstatus 2 flush_window 2 get_power_status 2 getreg 2 gzip_release 2 huft_build 2 huft_free 2 inflate_codes 2 inflate_dynamic 2 inflate_fixed 4 init 2 __initcall_init 14 init_once 2 klist_devices_get 2 klist_devices_put 2 load_elf_binary 2 load_elf_library 5 machvec_noop 4 machvec_noop_mm 2 mark_clean 2 maydump 2 message.1 3 m_next 2 modalias_show 3 m_start 3 m_stop 2 next_device 3 notesize 2 padzero 2 parse_options 2 proc_calc_metrics 2 raw_ioctl 2 read_block_bitmap 2 read_inode_bitmap 2 seq_next 2 seq_show 2 seq_start 2 seq_stop 2 set_brk 2 setkey 2 __setup_netdev_boot_setup 2 __setup_str_netdev_boot_setup 2 s_next 2 s_show 2 s_start 2 s_stop 2 state_show 2 state_store 2 store_uevent 2 try_to_fill_dentry 2 writenote 2 xdr_decode_fattr
It will also be extremely difficult to track down entries from compiler generated anonymous data areas. They are hard enough to isolate when looking at a single object. When all the anonymous data has been merged together in vmlinux, it will be beyond most people.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |