----- Original Message ----- > Hi Dave, > ... [ cut ] ... > The patch for crash tool can be found on github: > https://raw.githubusercontent.com/hziSot/crash-patches/41abc6f9c91c2a602973ff9564234395deadb80e/crash_speed_up_tree_list.patch > > Thanks, > Alexandr > Hi Alexandr, A few more comments/questions regarding the -S output. The help page descriptions of the list and tree -S options say that it does "exactly the same thing as -s", but here are a few situations where it doesn't. With "list -s", the parsed gdb output shows symbolic names following a member's value in the case of direct symbol-value matches: crash> list file_system_type.next -s file_system_type.mount 0xffffffff819db4a0 ffffffff819db4a0 mount = 0xffffffff8125b7b0 <sysfs_mount> ffffffff819dbee0 mount = 0xffffffff81261720 <rootfs_mount> ffffffff819d61a0 mount = 0xffffffff81218f40 <bd_mount> ffffffff819daf40 mount = 0xffffffff81249c60 <proc_mount> ffffffff8198f1c0 mount = 0xffffffff810fb590 <cgroup_mount> ffffffff819904a0 mount = 0xffffffff810fd610 <cpuset_mount> ffffffff819c09c0 mount = 0xffffffff81181e50 <shmem_mount> ffffffff81a11860 mount = 0xffffffff813faf40 <dev_mount> ffffffff819dc760 ... With "list -S", it shows this: crash> list file_system_type.next -S file_system_type.mount 0xffffffff819db4a0 ffffffff819db4a0 mount = 0xffffffff8125b7b0 ffffffff819dbee0 mount = 0xffffffff81261720 ffffffff819d61a0 mount = 0xffffffff81218f40 ffffffff819daf40 mount = 0xffffffff81249c60 ffffffff8198f1c0 mount = 0xffffffff810fb590 ffffffff819904a0 mount = 0xffffffff810fd610 ffffffff819c09c0 ... Somewhat related, "list -s" will also dump ASCII strings like this: crash> list file_system_type.next -s file_system_type.name 0xffffffff819db4a0 ffffffff819db4a0 name = 0xffffffff8189a0f2 "sysfs" ffffffff819dbee0 name = 0xffffffff8187e7cd "rootfs" ffffffff819d61a0 name = 0xffffffff8187ec39 "bdev" ffffffff819daf40 name = 0xffffffff8187279e "proc" ffffffff8198f1c0 name = 0xffffffff81894243 "cgroup" ffffffff819904a0 name = 0xffffffff81879c32 "cpuset" ffffffff819c09c0 name = 0xffffffff818a63f3 "tmpfs" ffffffff81a11860 ... Whereas "list -S", it just shows the address: crash> list file_system_type.next -S file_system_type.name 0xffffffff819db4a0 ffffffff819db4a0 name = 0xffffffff8189a0f2 ffffffff819dbee0 name = 0xffffffff8187e7cd ffffffff819d61a0 name = 0xffffffff8187ec39 ffffffff819daf40 name = 0xffffffff8187279e ffffffff8198f1c0 name = 0xffffffff81894243 ffffffff819904a0 name = 0xffffffff81879c32 ffffffff819c09c0 name = 0xffffffff818a63f3 ffffffff81a11860 ... Do you think it would be more useful to do either of the above, or would the direct symbol-matching and/or ASCII string recognition defeat the purpose of the -S speed-up? And also, if no members are appended to the struct name, it doesn't show anything. For example, with "list -s", the whole structure gets dumped when requested: crash> list file_system_type.next -s file_system_type 0xffffffff819db4a0 ffffffff819db4a0 struct file_system_type { name = 0xffffffff8189a0f2 "sysfs", fs_flags = 8, mount = 0xffffffff8125b7b0 <sysfs_mount>, kill_sb = 0xffffffff8125b6e0 <sysfs_kill_sb>, owner = 0x0, next = 0xffffffff819dbee0 <rootfs_fs_type>, fs_supers = { first = 0xffff880462a80138 }, s_lock_key = {<No data fields>}, s_umount_key = {<No data fields>}, s_vfs_rename_key = {<No data fields>}, s_writers_key = 0xffffffff819db4d8, i_lock_key = {<No data fields>}, i_mutex_key = {<No data fields>}, i_mutex_dir_key = {<No data fields>} } ffffffff819dbee0 struct file_system_type { name = 0xffffffff8187e7cd "rootfs", fs_flags = 0, mount = 0xffffffff81261720 <rootfs_mount>, kill_sb = 0xffffffff811e0ea0 <kill_litter_super>, owner = 0x0, next = 0xffffffff819d61a0 <bd_type>, fs_supers = { first = 0xffff8804687a0938 }, s_lock_key = {<No data fields>}, s_umount_key = {<No data fields>}, s_vfs_rename_key = {<No data fields>}, s_writers_key = 0xffffffff819dbf18, i_lock_key = {<No data fields>}, i_mutex_key = {<No data fields>}, i_mutex_dir_key = {<No data fields>} } ffffffff819d61a0 ... But with -S, you just get the addresses: crash> list file_system_type.next -S file_system_type 0xffffffff819db4a0 ffffffff819db4a0 ffffffff819dbee0 ffffffff819d61a0 ffffffff819daf40 ffffffff8198f1c0 ffffffff819904a0 ffffffff819c09c0 ffffffff81a11860 ffffffff819dc760 ... Should -S dump the whole structure, or should -S be specified as only being applicable with the "struct.member[,member]" argument format? Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
