Hi Dave! Sorry about the regression. I looked further through the code, and have modified it to only add the symbols for which it has actually identified a matching section, and to do it in a way which supports whatever sections are defined. This doesn't explain why a match isn't being found in the ia64 case, but should at least avoid the regression in the s390x case. I've also attached a test which one could run which dumps output which might help me fix things by tracing through loading the 'md5' module. By default the new code is off, as requested, and can be forced with a '-l' option to 'mod', e.g. crash> mod -l -s md5 Thanks again for the testing, and hopefully this will work for most people. It would be great if someone could send me output from the rarer platforms like ppc64 or 390 if it doesn't work. Happy New Year! -castor ________________________________ From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf Of Dave Anderson Sent: Tuesday, December 19, 2006 7:44 AM To: crash-utility(a)redhat.com; Castor Fu Subject: [Crash-utility] crash-4.0-3.14-sym.3.patch (was: modules and data /bss initialization) Hi Castor, While I have had some success with this patch on x86 and x86_64 machines, I haven't been so fortunate with other architectures. On ia64 machines for example, it quite often is unable to determine the .data segment address of a module, leaving it as 0, so there is no improvement over the current way it works. On the s390x, it actually causes a pretty serious regression. For example without the patch, here are the data addresses of the ext3 module before and after it gets loaded: $ /usr/bin/crash -s vmlinux-2.6.18-1.2767.el5 crash> sym -m ext3 | grep "([dD])" 208bfea0 (d) ext3_dir_operations 208bff88 (d) ext3_file_operations 208c0070 (d) ext3_ordered_aops 208c00e0 (d) ext3_writeback_aops 208c0150 (d) ext3_journalled_aops 208c01c0 (d) ext3_xattr_handler_map 208c01f8 (d) ext3_file_inode_operations 208c02a0 (d) ext3_dir_inode_operations 208c0348 (d) ext3_special_inode_operations 208c03f0 (d) ext3_fs_type 208c0430 (d) ext3_sops 208c04d8 (d) ext3_export_ops 208c0508 (d) ext3_qctl_operations 208c0560 (d) ext3_quota_operations 208c05c0 (d) ext3_symlink_inode_operations 208c0668 (d) ext3_fast_symlink_inode_operations 208c0710 (d) ext3_xattr_handlers 208c0740 (d) tokens 208c0a40 (d) ext3_xattr_user_handler 208c0a60 (d) ext3_xattr_trusted_handler 208c0a80 (d) ext3_xattr_acl_access_handler 208c0aa0 (d) ext3_xattr_acl_default_handler 208c0ac0 (d) ext3_xattr_security_handler 208c0b00 (d) __this_module crash> mod -s ext3 MODULE NAME SIZE OBJECT FILE 208c0b00 ext3 200208 /lib/modules/2.6.18-1.2767.el5/kernel/fs/ext3/ext3.ko crash> sym -m ext3 | grep "([dD])" 208bfea0 (d) ext3_dir_operations 208bff88 (d) ext3_file_operations 208c0070 (d) ext3_ordered_aops 208c00e0 (d) ext3_writeback_aops 208c0150 (d) ext3_journalled_aops 208c01c0 (d) ext3_xattr_handler_map 208c01f8 (d) ext3_file_inode_operations 208c02a0 (d) ext3_dir_inode_operations 208c0348 (d) ext3_special_inode_operations 208c03f0 (d) ext3_fs_type 208c0430 (d) ext3_sops 208c04d8 (d) ext3_export_ops 208c0508 (d) ext3_qctl_operations 208c0560 (d) ext3_quota_operations 208c05c0 (d) ext3_symlink_inode_operations 208c0668 (d) ext3_fast_symlink_inode_operations 208c0710 (d) ext3_xattr_handlers 208c0740 (d) tokens 208c0a40 (d) ext3_xattr_user_handler 208c0a60 (d) ext3_xattr_trusted_handler 208c0a80 (d) ext3_xattr_acl_access_handler 208c0aa0 (d) ext3_xattr_acl_default_handler 208c0ac0 (d) ext3_xattr_security_handler 208c0b00 (d) __this_module crash> That looks fine... However, with the patch applied, I get the following behavior: $ crash*14/crash -s vmlinux-2.6.18-1.2767.el5 crash> sym -m ext3 | grep "([dD])" 208bfea0 (d) ext3_dir_operations 208bff88 (d) ext3_file_operations 208c0070 (d) ext3_ordered_aops 208c00e0 (d) ext3_writeback_aops 208c0150 (d) ext3_journalled_aops 208c01c0 (d) ext3_xattr_handler_map 208c01f8 (d) ext3_file_inode_operations 208c02a0 (d) ext3_dir_inode_operations 208c0348 (d) ext3_special_inode_operations 208c03f0 (d) ext3_fs_type 208c0430 (d) ext3_sops 208c04d8 (d) ext3_export_ops 208c0508 (d) ext3_qctl_operations 208c0560 (d) ext3_quota_operations 208c05c0 (d) ext3_symlink_inode_operations 208c0668 (d) ext3_fast_symlink_inode_operations 208c0710 (d) ext3_xattr_handlers 208c0740 (d) tokens 208c0a40 (d) ext3_xattr_user_handler 208c0a60 (d) ext3_xattr_trusted_handler 208c0a80 (d) ext3_xattr_acl_access_handler 208c0aa0 (d) ext3_xattr_acl_default_handler 208c0ac0 (d) ext3_xattr_security_handler 208c0b00 (d) __this_module crash> mod -s ext3 MODULE NAME SIZE OBJECT FILE 208c0b00 ext3 200208 /lib/modules/2.6.18-1.2767.el5/kernel/fs/ext3/ext3.ko crash> sym -m ext3 | grep "([dD])" 0 (D) __this_module 0 (D) ext3_dir_operations 0 (D) ext3_file_inode_operations 0 (d) tokens a8 (D) ext3_dir_inode_operations e8 (D) ext3_file_operations 150 (D) ext3_special_inode_operations 1d0 (d) ext3_ordered_aops 1f8 (d) ext3_fs_type 238 (d) ext3_sops 240 (d) ext3_writeback_aops 2b0 (d) ext3_journalled_aops 2e0 (d) ext3_export_ops 300 (D) ext3_xattr_user_handler 310 (d) ext3_qctl_operations 320 (d) ext3_xattr_handler_map 320 (D) ext3_xattr_trusted_handler 340 (D) ext3_xattr_acl_access_handler 360 (D) ext3_xattr_acl_default_handler 368 (d) ext3_quota_operations 380 (D) ext3_xattr_security_handler 3c8 (D) ext3_symlink_inode_operations 470 (D) ext3_fast_symlink_inode_operations 518 (D) ext3_xattr_handlers crash> I haven't been able to test it on a ppc64 or s390. (That's why I asked for help from others on the mailing list to test it out, but I didn't get any takers...) In any case, as much as I like what the patch wants to do, I can't accept it given such a serious regression. Perhaps it could be made an experimental run-time option that could be turned on prior to doing any "mod" commands, leaving the current behaviour in place by default? Thanks, Dave