7:24 p.m.
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