RE: [Crash-utility] modules and data / bss initialization
by Castor Fu
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: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com]On 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: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com]On 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
18 years, 1 month
Re: [Crash-utility] support for older gcc
by Daniel Li
You are certainly right... the fix is still in crash, as I checked with
earlier dumps. I did see some error messages regarding pid_hash array
with latest crash on our dumps. However, so far it seemed to be a
different problem. Will investigate and may bug you later.
18 years, 1 month
RE: [Crash-utility] modules and data / bss initialization
by Castor Fu
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: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com]On 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
18 years, 1 month
RE: [Crash-utility] modules and data / bss initialization
by Castor Fu
The warning message here is a little strange.
The symbol matches as being in the 'bss', but appears to be
being located outside the bss segment.
Once I think I've identified a segment, I try to skip over the
rest of it. There's an assumption (and I probably should have
written an assertion) that symbols we scan over starting at mod_symtable
are monotonically increasing. Is that not true?
The clipping on the longs is annoying. I tend to rely on gcc catching
those for me.
Thanks for the testing!
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com]On 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
18 years, 1 month
crash version 4.0-3.14 is available
by Dave Anderson
- Tentatively scheduled for RHEL5-GA
- Added support for Magnus Damm's latest kexec/kdump patch for Xen.
The ELF header of the vmcore, which is a full memory dump of the
dom0/hypervisor combination, contains a XEN_ELFNOTE_CRASH_INFO note
that contains the pfn_to_mfn_list_list value for dom0, allowing
pfn-to-mfn translations may be made for crash analysis of the dom0
linux kernel. (anderson(a)redhat.com)
- Added support for recognizing the zero-fill segments in ELF vmcore
files created by the makedumpfile command from kdump /proc/vmcore files.
Without this patch, ELF vmcore files generated by makedumpfile could
only be used by gdb. (anderson(a)redhat.com)
- Updated the 4.0-3.4 patch that addressed the bogus kernel-/proc/version
mismatch initialization failures using recent s390x vmlinux files that
contain an ASCII character just preceding the Linux version string.
That patch fixed the problem when the vmlinux file name was placed on
the crash command line; this version also fixes it when "crash" is
entered alone on the command line, and it has to search for the vmlinux
file. (anderson(a)redhat.com)
Download from: http://people.redhat.com/anderson
18 years, 1 month
RE: [Crash-utility] modules and data / bss initialization
by Castor Fu
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.6
since modules will end with .ko
I hope this looks good to others....
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com]On Behalf Of Castor Fu
Sent: Monday, November 20, 2006 2:27 PM
To: Discussion list for crash utility usage, maintenance and development
Subject: RE: [Crash-utility] modules and data / bss initialization
Yup -- it's easy enough to work around when one knows
what one wants, but it's kind of painful. I have no idea why people
removed all this functionality from insmod. I suppose someone wants
to hide more info?
If nobody else has fixed this I'll either do it myself or get someone else to do it in
the next week or so.
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com]On Behalf Of Dave Anderson
Sent: Monday, November 20, 2006 2:04 PM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] modules and data / bss initialization
Castor Fu wrote:
Under linux 2.6 it seems that crash is not figuring out the locations
of any sections of modules other than the text section.
This means that things like 'sym modvar1' can find the correct location
but 'p modvar1' does not work.
I guess that there are a couple of possibilities here:
1. if CONFIG_KALLSYMS is set, one could look through the sect_attrs
for each of the sections and initialize the segments.
2. if CONFIG_KALLSYMS is not set, we would have to try to match
offsets of some variables from the object file with the existing offsets
in the kernel.
Clearly [2] is the 'better' solution because it doesn't
require CONFIG_KALLSYMS to be set, but it seems like more work.
Has anyone done either of these yet? If not does it seem like I've described the
problem correctly?
Thanks,
castor
It's been years since that code has been tinkered with,
and since I don't debug much module code, I wasn't even
aware that there was a 2.6-only difference. I thought that
the add-symbol-file operation would properly assign the
module's msymbols with the correct addresses for data
symbols, which it does do correctly for the text symbols.
(I think that's the issue with the "p" command, i.e., the
embedded gdb is still using the offset value from
the object file and failing...)
Anyway, you can still do a "whatis modvar1", get the data type,
and then either do a "struct" command with the address, or
come up with a cobbled-together gdb print command, right?
Dave
18 years, 1 month
