Oops, I found some problems with that version... Some data was not always
initialized and there were some things which were just lucky to work.
I've attached a new patch.
Sorry about that folks,
castor-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Castor Fu Sent: Monday, December 04, 2006 11:16 AM To: Discussion list for crash utility usage, maintenance and development Subject: RE: [Crash-utility] modules and data / bss initialization I'm attaching a revised patch against 4.0-3.14... This should work a bit better as I no longer make assumptions about the ordering of symbols, it's less whiny, and I even compiled with with -Werror so those sign-extension problems should be gone. Thanks for the feedback! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Anderson Sent: Friday, December 01, 2006 11:46 AM To: Discussion list for crash utility usage, maintenance and development Subject: Re: [Crash-utility] modules and data / bss initialization Castor Fu wrote: I don't think this made it out earlier...Here's a fix. I've also added something so 'MODULES_IN_CWD' will work on 2.6since modules will end with .koI hope this looks good to others.... Hi Castor, Upon quick testing with RHEL4 and RHEL5 x86_64 kernels, this patch certainly looks promising... Although I don't particularly care to see these messages: ffffffff8810ae80 serio_raw 41157 /lib/modules/2.6.18-1.2747.el5/kernel/drivers/input/serio/serio_raw.ko ffffffff8811b580 uhci_hcd 59353 /lib/modules/2.6.18-1.2747.el5/kernel/drivers/usb/host/uhci-hcd.ko ffffffff88130b00 shpchp 73069 /lib/modules/2.6.18-1.2747.el5/kernel/drivers/pci/hotplug/shpchp.ko unexpected sym __key.10825 8814a180 sec .bss offset e180 mod_base 8813c000 XXX sym __key.10825 @ 8814a180 bfd val 0 section .bss unexpected sym __key.10826 8814a180 sec .bss offset e180 mod_base 8813c000 XXX sym __key.10826 @ 8814a180 bfd val 0 section .bss ffffffff88141f80 i2c_core 57793 /lib/modules/2.6.18-1.2747.el5/kernel/drivers/i2c/i2c-core.ko I would think they could be CRASHDEBUG(1)'d, couldn't they? Plus, those error messages will clip 64-bit values as shown above. I'm also presuming that the new add-symbol-file operation will harmlessly take a "0" mod_data_start, mod_rodata_start or mod_bss_start address argument; seemingly it does, since several of my test modules have 0 as one or more of those start addresses. Anyway, I also would be interested in the experiences of others on the list who are using different architectures and kernel versions. Thanks, Dave
crash-4.0-3.14-sym.1.patch
Description: crash-4.0-3.14-sym.1.patch
-- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
