Re: bt -f (ia64)
by Dave Anderson
----- "Cliff Wickman" <cpw(a)sgi.com> wrote:
> Hi Dave,
>
> In using crash yesterday on an ia64 dump I found that "bt -f" did
> not show contents of the stack. Neither memory stack nor stacked registers.
> (It does show the "bsp" pointer to backing storage, which helps)
>
> It must have displayed the stacks' contents in the past, as the help for
> bt says:
> -f display all stack data contained in a frame; this option can be
> used to determine the arguments passed to each function; on ia64,
> the argument register contents are dumped.
>
> I don't find any discussion on this subject.
> Can you tell me anything about the status of it?
>
> Thanks.
> -Cliff
As the help page states, the ia64 "bt -f" option dumps the arguments
to each function. On the other architectures, it dumps the data in
each stack frame as an aid in finding the function arguments.
If you want to look at raw ia64 stack contents, use "bt -r".
Dave
15 years, 10 months
bt -f (ia64)
by Cliff Wickman
Hi Dave,
In using crash yesterday on an ia64 dump I found that "bt -f" did
not show contents of the stack. Neither memory stack nor
stacked registers.
(It does show the "bsp" pointer to backing storage, which helps)
It must have displayed the stacks' contents in the past, as the help for
bt says:
-f display all stack data contained in a frame; this option can be
used to determine the arguments passed to each function; on ia64,
the argument register contents are dumped.
I don't find any discussion on this subject.
Can you tell me anything about the status of it?
Thanks.
-Cliff
15 years, 10 months
Re: [PATCH] crash: execution machine pagesize differs
by Cliff Wickman
Never mind!
As Hedi Berriche pointed out, Bernhard Walle fixed this 2 weeks ago.
> This patch allows a machine to read a dump when that dump was taken on
> a machine with a larger page size.
> e.g. we had a dump of a 64k pagesize system, and ran crash on a
> machine with a 16k pagesize.
>
> Diffed against crash-4.0-7.6
>
15 years, 10 months
[PATCH] crash: execution machine pagesize differs
by Cliff Wickman
This patch allows a machine to read a dump when that dump was taken on
a machine with a larger page size.
e.g. we had a dump of a 64k pagesize system, and ran crash on a
machine with a 16k pagesize.
Diffed against crash-4.0-7.6
Signed-off-by: Cliff Wickman <cpw(a)sgi.com>
---
diskdump.c | 25 +++++++++++++++++++------
tools.c | 2 ++
2 files changed, 21 insertions(+), 6 deletions(-)
Index: crash-4.0-7.6.ia64/diskdump.c
===================================================================
--- crash-4.0-7.6.ia64.orig/diskdump.c
+++ crash-4.0-7.6.ia64/diskdump.c
@@ -107,7 +107,7 @@ static int read_dump_header(char *file)
struct disk_dump_sub_header *sub_header = NULL;
struct kdump_sub_header *sub_header_kdump = NULL;
int bitmap_len;
- const int block_size = (int)sysconf(_SC_PAGESIZE);
+ int block_size = (int)sysconf(_SC_PAGESIZE);
off_t offset;
const off_t failed = (off_t)-1;
ulong pfn;
@@ -165,12 +165,25 @@ static int read_dump_header(char *file)
machine_type_mismatch(file, "PPC64", NULL, 0))
goto err;
- if (header->block_size != block_size) {
- error(INFO, "%s: block size in the dump header does not match"
- " with system page size\n",
- DISKDUMP_VALID() ? "diskdump" : "compressed kdump");
- goto err;
+ /*
+ * Up to here, the header was assumed to be one page in size.
+ * We checked utsname and signature, which are up front in the
+ * header. But all of the task array may not have been entirely
+ * read if the executing machines's page size is smaller than that
+ * of the dumped machine.
+ * Re-read the entire header if its block_size is bigger than the
+ * executing machine's page size.
+ */
+ if (header->block_size > block_size) {
+ block_size = header->block_size;
+ free(header);
+ if ((header = malloc(block_size)) == NULL)
+ error(FATAL,
+ "diskdump / compressed kdump: cannot malloc block_size buffer\n");
+ lseek(dd->dfd, 0, SEEK_SET);
+ read(dd->dfd, header, block_size);
}
+
dd->block_size = block_size;
dd->block_shift = ffs(block_size) - 1;
15 years, 10 months
Fwd: [PATCH] crash: load of module types LKCD_KERNTYPES
by Dave Anderson
----- Forwarded Message -----
From: "Cliff Wickman" <cpw(a)sgi.com>
To: "Dave Anderson" <anderson(a)redhat.com>
Sent: Thursday, January 29, 2009 4:23:22 PM GMT -05:00 US/Canada Eastern
Subject: Re: [PATCH] crash: load of module types LKCD_KERNTYPES
Hi Dave,
On Thu, Jan 29, 2009 at 03:43:03PM -0500, Dave Anderson wrote:
>
> ----- "Cliff Wickman" <cpw(a)sgi.com> wrote:
>
> > This patch allows additional kerntypes files to be loaded as module
> > debuginfo (namelist) files.
> >
> > It's a bit of a kludge, as sym -s module <file> still requires
> > that these types be associated with a loaded module. (but its use
> > would only be desirable when there are loaded modules, so that
> > restriction should not be a problem)
>
> The patch looks fine (segregated), and I've queued it for the next release.
>
> But I'm not entirely clear what you mean by the comment above? You've
> got this kerntypes object file that was created from a kernel module, and
> you can load its debuginfo data individually with "mod -s module kerntypes".
> What's the kludge again?
Ok, not a kludge if the kerntypes was built from the module that you
name in the mod -s command.
But I would lump together the types from hundreds of modules into a
single compact file that I can load if needed. When I mod -s this file
it has to be associated with some loaded module.
-Cliff
>
> >
> > Tested against a live 2.6.27 kernel.
> > Diffed against crash-4.0-7.6
> >
> > Signed-off-by: Cliff Wickman <cpw(a)sgi.com>
> >
> > ---
> > symbols.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > Index: crash-4.0-7.6.ia64/symbols.c
> > ===================================================================
> > --- crash-4.0-7.6.ia64.orig/symbols.c
> > +++ crash-4.0-7.6.ia64/symbols.c
> > @@ -7992,8 +7992,12 @@ load_module_symbols(char *modref, char *
> > error(FATAL, "cannot determine object file format: %s\n",
> > namelist);
> >
> > - if (!(bfd_get_file_flags(mbfd) & HAS_SYMS))
> > - error(FATAL, "no symbols in object file: %s\n",
> > namelist);
> > + if (LKCD_KERNTYPES() && file_elf_version(namelist) ==
> > EV_DWARFEXTRACT) {
> > + goto add_symbols; /* no symbols, add the debuginfo */
> > + }
> > +
> > + if (!(bfd_get_file_flags(mbfd) & HAS_SYMS))
> > + error(FATAL, "no symbols in object file: %s\n", namelist);
> >
> > symcount = bfd_read_minisymbols(mbfd, FALSE, &minisyms, &size);
> > if (symcount < 0)
--
Cliff Wickman
Silicon Graphics, Inc.
cpw(a)sgi.com
(651) 683-3824
15 years, 10 months
[PATCH] crash: load of module types LKCD_KERNTYPES
by Cliff Wickman
This patch allows additional kerntypes files to be loaded as module
debuginfo (namelist) files.
It's a bit of a kludge, as sym -s module <file> still requires
that these types be associated with a loaded module. (but its use
would only be desirable when there are loaded modules, so that
restriction should not be a problem)
Tested against a live 2.6.27 kernel.
Diffed against crash-4.0-7.6
Signed-off-by: Cliff Wickman <cpw(a)sgi.com>
---
symbols.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
Index: crash-4.0-7.6.ia64/symbols.c
===================================================================
--- crash-4.0-7.6.ia64.orig/symbols.c
+++ crash-4.0-7.6.ia64/symbols.c
@@ -7992,8 +7992,12 @@ load_module_symbols(char *modref, char *
error(FATAL, "cannot determine object file format: %s\n",
namelist);
- if (!(bfd_get_file_flags(mbfd) & HAS_SYMS))
- error(FATAL, "no symbols in object file: %s\n", namelist);
+ if (LKCD_KERNTYPES() && file_elf_version(namelist) == EV_DWARFEXTRACT) {
+ goto add_symbols; /* no symbols, add the debuginfo */
+ }
+
+ if (!(bfd_get_file_flags(mbfd) & HAS_SYMS))
+ error(FATAL, "no symbols in object file: %s\n", namelist);
symcount = bfd_read_minisymbols(mbfd, FALSE, &minisyms, &size);
if (symcount < 0)
15 years, 10 months
Re: [Crash-utility] crash mod -S problem
by Dave Anderson
----- "Cliff Wickman" <cpw(a)sgi.com> wrote:
> On Thu, Jan 29, 2009 at 11:23:49AM -0500, Dave Anderson wrote:
> >
> > ----- "Cliff Wickman" <cpw(a)sgi.com> wrote:
> >
> > > Hi Dave, and company,
> > >
> > > I have a question. Perhaps this is a known issue -- should I be looking
> > > in an archive somewhere?
> > >
> > > The crash command "mod -S" is messing up the address list.
> > >
> > > This is crash-4.0-7.6, running on ia64.
> > >
> > > Note how the value of module symbol xfs_ioerror_alert has changed
> > > after the mod -S.
> > >
> > > Is this a crash problem? Or my problem? (there are several ?'s in
> > > the mod -S output, including on the xfs module)
> >
> > Good question -- I don't know.
> >
> > It appears that the determination of the module's text starting location
> > is being changed by the "mod -S". That can happen when the symbols.c
> > function store_load_module_symbols() calls calculate_load_order_v2(),
> > which can change the text start location that was initialized during
> > the crash session initialization by store_module_symbols_v2().
> >
> > The question is which text start address value is correct.
> >
> > Try this:
> >
> > $ crash -s
> > crash> help -s | grep mod_text_start > before
> > crash> mod -S
> > ... [ snip ] ...
> > crash> help -s | grep mod_text_start > after
> > crash> q
> >
> > $ diff before after
>
> It changed:
> $ diff before after
> 1,3c1,3
> < mod_text_start: a0000002093f0000 (0)
> < mod_text_start: a000000209410000 (0)
> < mod_text_start: a000000209430000 (0)
> ---
> > mod_text_start: a0000002093f49e0 (49e0)
> > mod_text_start: a000000209412040 (2040)
> > mod_text_start: a000000209433968 (3968)
> 5,7c5,7
> < mod_text_start: a000000209470000 (0)
> < mod_text_start: a0000002094b0000 (0)
> < mod_text_start: a000000209510000 (0)
> ---
> > mod_text_start: a000000209483c68 (13c68)
> > mod_text_start: a0000002094d31a8 (231a8)
> > mod_text_start: a00000020951c4d8 (c4d8)
> [snip]
>
>
> > Typically it won't change, and the before and after files are
> identical.
> >
> > But on your system it would appear that many (if not all) of the modules are
> > changing their mod_text_start values upon running "mod -S".
> >
> > You can also determine which value is correct by doing a "dis <function>"
> > command before and after the "mod -S".
>
> Yes, we were doing a "dis" when we noticed the problem. The addresses
> are correct before the mod -S.
>
> So you suspect the problem is in calculate_load_order_v2() ?
>
> -Cliff
If the text was correct *before* the "mod -S", then yes, the
text base address was changed by calculate_load_order_v2().
My first response started a cc: to Castor Fu, the author of
calculate_load_order_v2() function, because I'd be interested
in what he has to say on the matter. He's on west coast time.
As I understand it, calculate_load_order_v2() is taking the
first (lowest) symbol of each module section (as determined
during initialization), and searches for it in the module
object file. And when it finds it, it calls bfd_get_section_name()
to get the section name string, and based upon that updates the
fields associated with that section. For the .text section it
normally finds the first text symbol to have an offset value of 0,
and therefore no changes are made to the mod_text_offset. It looks
like it's finding the "first" text symbol at a higher offset?
If you enter "set debug 3", and then do a "mod -s <module-name>",
you'll see its machinations on a given module.
Dave
>
>
> > > crash> sym xfs_ioerror_alert
> > > a000000209955f80 (t) xfs_ioerror_alert
> > >
> > > crash> mod -S
> > > MODULE NAME SIZE OBJECT FILE
> > > a0000002093fc088 scsi_transport_spi 50672
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/scsi/scsi_transport_spi.ko
> > > mod: ioc4: last symbol is not _MODULE_END_ioc4?
> > > a000000209412fa8 ioc4 13056
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/misc/ioc4.ko
> > > mod: scsi_tgt: last symbol is not _MODULE_END_scsi_tgt?
> > > a000000209435cd0 scsi_tgt 24640
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/scsi/scsi_tgt.ko
> > > a000000209453610 sgiioc4 14656
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/ide/pci/sgiioc4.ko
> > > mod: mptbase: last symbol is not _MODULE_END_mptbase?
> > > a000000209497298 mptbase 166540
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/message/fusion/mptbase.ko
> > > a0000002094f8008 scsi_mod 299024
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/scsi/scsi_mod.ko
> > > a000000209547038 ide_core 229280
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/ide/ide-core.ko
> > > a000000209583da0 qla1280 148256
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/scsi/qla1280.ko
> > > mod: scsi_transport_fc: last symbol is not
> > > _MODULE_END_scsi_transport_fc?
> > > a0000002095b51d0 scsi_transport_fc 88156
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/scsi/scsi_transport_fc.ko
> > > a0000002095d7bd8 mptfc 32776
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/message/fusion/mptfc.ko
> > > mod: mptscsih: last symbol is not _MODULE_END_mptscsih?
> > > a000000209610618 mptscsih 68816
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/message/fusion/mptscsih.ko
> > > a000000209631208 hwmon 5304
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/hwmon/hwmon.ko
> > > mod: thermal_sys: last symbol is not _MODULE_END_thermal_sys?
> > > a000000209655c90 thermal_sys 24656
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/thermal/thermal_sys.ko
> > > a000000209679b40 thermal 41144
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/acpi/thermal.ko
> > > a0000002096b4340 processor 85008
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/acpi/processor.ko
> > > a0000002096d23c8 fan 9960
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/acpi/fan.ko
> > > a000000209718490 mptspi 34936
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/message/fusion/mptspi.ko
> > > a000000209730e00 ide_generic 4264
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/ide/ide-generic.ko
> > > a0000002097506f0 crc_t10dif 2336
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/lib/crc-t10dif.ko
> > > a000000209773430 button 14312
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/acpi/button.ko
> > > a0000002097b1380 sd_mod 72432
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/scsi/sd_mod.ko
> > > a0000002097e12a0 sg 71976
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/scsi/sg.ko
> > > a0000002098124b8 cdrom 77752
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/cdrom/cdrom.ko
> > > mod: cannot find or load object file for ide_cd_mod module
> > > mod: libphy: last symbol is not _MODULE_END_libphy?
> > > a000000209859928 libphy 40168
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/net/phy/libphy.ko
> > > mod: xfs: last symbol is not _MODULE_END_xfs?
> > > a0000002099abaf0 xfs 1233888
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/fs/xfs/xfs.ko
> > > a0000002099ed130 mptctl 188064
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/message/fusion/mptctl.ko
> > > a000000209a04690 mmtimer 18836
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/char/mmtimer.ko
> > > a000000209a53a68 kdbm_pg 16632
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/kdb/modules/kdbm_pg.ko
> > > a000000209a70a48 kdbm_sched 3296
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/kdb/modules/kdbm_sched.ko
> > > a000000209a91b28 kdbm_task 40608
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/kdb/modules/kdbm_task.ko
> > > a000000209b1fba0 qla2xxx 463704
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/scsi/qla2xxx/qla2xxx.ko
> > > a000000209b850c0 tg3 284796
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/net/tg3.ko
> > > mod: dm_mod: last symbol is not _MODULE_END_dm_mod?
> > > a000000209ff25f8 dm_mod 143048
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/md/dm-mod.ko
> > > a00000020a016518 kdbm_vm 28112
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/kdb/modules/kdbm_vm.ko
> > > a00000020a031f20 mspec 16932
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/char/mspec.ko
> > > a00000020a05e290 numatools 59232
> > > /lib/modules/2.6.27.8-1-sgidev/up
> > > dates/numatools.ko
> > > a00000020a073f38 xp 17216
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/misc/sgi-xp/xp.ko
> > > a00000020a0b4c08 gru 87288
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/misc/sgi-gru/gru.ko
> > > a00000020a0d38e0 sgi_gpl_lib 15272
> > > /lib/modules/2.6.27.8-1-sgidev/we
> > > ak-updates/extra/gpl_lib/sgi-gpl-lib.ko
> > > a00000020a115c58 myri10ge 91048
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/net/myri10ge/myri10ge.ko
> > > mod: loop: last symbol is not _MODULE_END_loop?
> > > a00000020a138478 loop 34788
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/block/loop.ko
> > > mod: cannot find or load object file for nls_iso8859_1 module
> > > a00000020a18ac80 sgi_os_lib 111192
> > > /lib/modules/2.6.27.8-1-sgidev/we
> > > ak-updates/extra/os_lib/sgi-os-lib.ko
> > > mod: crypto_blkcipher: last symbol is not
> > > _MODULE_END_crypto_blkcipher?
> > > a00000020a1a8c00 crypto_blkcipher 36848
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/crypto/crypto_blkcipher.ko
> > > a00000020a1c6fd0 dm_crypt 29784
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/drivers/md/dm-crypt.ko
> > > a00000020a1e4cd8 binfmt_misc 20444
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/fs/binfmt_misc.ko
> > > a00000020a25d758 xpmem 122536
> > > /lib/modules/2.6.27.8-1-sgidev/up
> > > dates/xpmem.ko
> > > a00000020a28d518 fuse 121352
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/fs/fuse/fuse.ko
> > > mod: ipv6: last symbol is not _MODULE_END_ipv6?
> > > a00000020a358030 ipv6 627656
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/net/ipv6/ipv6.ko
> > > mod: sgi_xvm: last symbol is not _MODULE_END_sgi_xvm?
> > > a00000020a41a520 sgi_xvm 704400
> > > /lib/modules/2.6.27.8-1-sgidev/we
> > > ak-updates/extra/xvm/sgi-xvm.ko
> > > a00000020a46ba78 autofs4 48656
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/fs/autofs4/autofs4.ko
> > > a00000020a482090 exportfs 8944
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/fs/exportfs/exportfs.ko
> > > mod: auth_rpcgss: last symbol is not _MODULE_END_auth_rpcgss?
> > > a00000020a4b3ee0 auth_rpcgss 82696
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/net/sunrpc/auth_gss/auth_rpcgss.ko
> > > mod: nfs_acl: last symbol is not _MODULE_END_nfs_acl?
> > > a00000020a4d17b8 nfs_acl 6648
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/fs/nfs_common/nfs_acl.ko
> > > a00000020a5b1e88 sunrpc 472176
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/net/sunrpc/sunrpc.ko
> > > mod: lockd: last symbol is not _MODULE_END_lockd?
> > > a00000020a5f1e00 lockd 141416
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/fs/lockd/lockd.ko
> > > a00000020a6aaa98 nfs 641664
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/fs/nfs/nfs.ko
> > > a00000020a73ea30 nfsd 523168
> > > /lib/modules/2.6.27.8-1-sgidev/ke
> > > rnel/fs/nfsd/nfsd.ko
> > >
> > > crash> sym xfs_ioerror_alert
> > > a000000209992d18 (T) xfs_ioerror_alert
> > >
> > > Thanks.
> > > -Cliff
> > >
> > > --
> > > Crash-utility mailing list
> > > Crash-utility(a)redhat.com
> > > https://www.redhat.com/mailman/listinfo/crash-utility
> >
> > --
> > Crash-utility mailing list
> > Crash-utility(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
>
> --
> Cliff Wickman
> Silicon Graphics, Inc.
> cpw(a)sgi.com
> (651) 683-3824
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
15 years, 10 months
Re: [Crash-utility] crash mod -S problem
by Dave Anderson
----- "Cliff Wickman" <cpw(a)sgi.com> wrote:
> Hi Dave, and company,
>
> I have a question. Perhaps this is a known issue -- should I be looking
> in an archive somewhere?
>
> The crash command "mod -S" is messing up the address list.
>
> This is crash-4.0-7.6, running on ia64.
>
> Note how the value of module symbol xfs_ioerror_alert has changed
> after the mod -S.
>
> Is this a crash problem? Or my problem? (there are several ?'s in
> the mod -S output, including on the xfs module)
Good question -- I don't know.
It appears that the determination of the module's text starting location
is being changed by the "mod -S". That can happen when the symbols.c
function store_load_module_symbols() calls calculate_load_order_v2(),
which can change the text start location that was initialized during
the crash session initialization by store_module_symbols_v2().
The question is which text start address value is correct.
Try this:
$ crash -s
crash> help -s | grep mod_text_start > before
crash> mod -S
... [ snip ] ...
crash> help -s | grep mod_text_start > after
crash> q
$ diff before after
Typically it won't change, and the before and after files are identical.
But on your system it would appear that many (if not all) of the modules are
changing their mod_text_start values upon running "mod -S".
You can also determine which value is correct by doing a "dis <function>"
command before and after the "mod -S".
Dave
> crash> sym xfs_ioerror_alert
> a000000209955f80 (t) xfs_ioerror_alert
>
> crash> mod -S
> MODULE NAME SIZE OBJECT FILE
> a0000002093fc088 scsi_transport_spi 50672
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/scsi/scsi_transport_spi.ko
> mod: ioc4: last symbol is not _MODULE_END_ioc4?
> a000000209412fa8 ioc4 13056
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/misc/ioc4.ko
> mod: scsi_tgt: last symbol is not _MODULE_END_scsi_tgt?
> a000000209435cd0 scsi_tgt 24640
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/scsi/scsi_tgt.ko
> a000000209453610 sgiioc4 14656
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/ide/pci/sgiioc4.ko
> mod: mptbase: last symbol is not _MODULE_END_mptbase?
> a000000209497298 mptbase 166540
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/message/fusion/mptbase.ko
> a0000002094f8008 scsi_mod 299024
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/scsi/scsi_mod.ko
> a000000209547038 ide_core 229280
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/ide/ide-core.ko
> a000000209583da0 qla1280 148256
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/scsi/qla1280.ko
> mod: scsi_transport_fc: last symbol is not
> _MODULE_END_scsi_transport_fc?
> a0000002095b51d0 scsi_transport_fc 88156
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/scsi/scsi_transport_fc.ko
> a0000002095d7bd8 mptfc 32776
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/message/fusion/mptfc.ko
> mod: mptscsih: last symbol is not _MODULE_END_mptscsih?
> a000000209610618 mptscsih 68816
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/message/fusion/mptscsih.ko
> a000000209631208 hwmon 5304
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/hwmon/hwmon.ko
> mod: thermal_sys: last symbol is not _MODULE_END_thermal_sys?
> a000000209655c90 thermal_sys 24656
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/thermal/thermal_sys.ko
> a000000209679b40 thermal 41144
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/acpi/thermal.ko
> a0000002096b4340 processor 85008
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/acpi/processor.ko
> a0000002096d23c8 fan 9960
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/acpi/fan.ko
> a000000209718490 mptspi 34936
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/message/fusion/mptspi.ko
> a000000209730e00 ide_generic 4264
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/ide/ide-generic.ko
> a0000002097506f0 crc_t10dif 2336
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/lib/crc-t10dif.ko
> a000000209773430 button 14312
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/acpi/button.ko
> a0000002097b1380 sd_mod 72432
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/scsi/sd_mod.ko
> a0000002097e12a0 sg 71976
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/scsi/sg.ko
> a0000002098124b8 cdrom 77752
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/cdrom/cdrom.ko
> mod: cannot find or load object file for ide_cd_mod module
> mod: libphy: last symbol is not _MODULE_END_libphy?
> a000000209859928 libphy 40168
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/net/phy/libphy.ko
> mod: xfs: last symbol is not _MODULE_END_xfs?
> a0000002099abaf0 xfs 1233888
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/fs/xfs/xfs.ko
> a0000002099ed130 mptctl 188064
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/message/fusion/mptctl.ko
> a000000209a04690 mmtimer 18836
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/char/mmtimer.ko
> a000000209a53a68 kdbm_pg 16632
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/kdb/modules/kdbm_pg.ko
> a000000209a70a48 kdbm_sched 3296
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/kdb/modules/kdbm_sched.ko
> a000000209a91b28 kdbm_task 40608
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/kdb/modules/kdbm_task.ko
> a000000209b1fba0 qla2xxx 463704
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/scsi/qla2xxx/qla2xxx.ko
> a000000209b850c0 tg3 284796
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/net/tg3.ko
> mod: dm_mod: last symbol is not _MODULE_END_dm_mod?
> a000000209ff25f8 dm_mod 143048
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/md/dm-mod.ko
> a00000020a016518 kdbm_vm 28112
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/kdb/modules/kdbm_vm.ko
> a00000020a031f20 mspec 16932
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/char/mspec.ko
> a00000020a05e290 numatools 59232
> /lib/modules/2.6.27.8-1-sgidev/up
> dates/numatools.ko
> a00000020a073f38 xp 17216
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/misc/sgi-xp/xp.ko
> a00000020a0b4c08 gru 87288
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/misc/sgi-gru/gru.ko
> a00000020a0d38e0 sgi_gpl_lib 15272
> /lib/modules/2.6.27.8-1-sgidev/we
> ak-updates/extra/gpl_lib/sgi-gpl-lib.ko
> a00000020a115c58 myri10ge 91048
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/net/myri10ge/myri10ge.ko
> mod: loop: last symbol is not _MODULE_END_loop?
> a00000020a138478 loop 34788
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/block/loop.ko
> mod: cannot find or load object file for nls_iso8859_1 module
> a00000020a18ac80 sgi_os_lib 111192
> /lib/modules/2.6.27.8-1-sgidev/we
> ak-updates/extra/os_lib/sgi-os-lib.ko
> mod: crypto_blkcipher: last symbol is not
> _MODULE_END_crypto_blkcipher?
> a00000020a1a8c00 crypto_blkcipher 36848
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/crypto/crypto_blkcipher.ko
> a00000020a1c6fd0 dm_crypt 29784
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/drivers/md/dm-crypt.ko
> a00000020a1e4cd8 binfmt_misc 20444
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/fs/binfmt_misc.ko
> a00000020a25d758 xpmem 122536
> /lib/modules/2.6.27.8-1-sgidev/up
> dates/xpmem.ko
> a00000020a28d518 fuse 121352
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/fs/fuse/fuse.ko
> mod: ipv6: last symbol is not _MODULE_END_ipv6?
> a00000020a358030 ipv6 627656
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/net/ipv6/ipv6.ko
> mod: sgi_xvm: last symbol is not _MODULE_END_sgi_xvm?
> a00000020a41a520 sgi_xvm 704400
> /lib/modules/2.6.27.8-1-sgidev/we
> ak-updates/extra/xvm/sgi-xvm.ko
> a00000020a46ba78 autofs4 48656
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/fs/autofs4/autofs4.ko
> a00000020a482090 exportfs 8944
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/fs/exportfs/exportfs.ko
> mod: auth_rpcgss: last symbol is not _MODULE_END_auth_rpcgss?
> a00000020a4b3ee0 auth_rpcgss 82696
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/net/sunrpc/auth_gss/auth_rpcgss.ko
> mod: nfs_acl: last symbol is not _MODULE_END_nfs_acl?
> a00000020a4d17b8 nfs_acl 6648
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/fs/nfs_common/nfs_acl.ko
> a00000020a5b1e88 sunrpc 472176
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/net/sunrpc/sunrpc.ko
> mod: lockd: last symbol is not _MODULE_END_lockd?
> a00000020a5f1e00 lockd 141416
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/fs/lockd/lockd.ko
> a00000020a6aaa98 nfs 641664
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/fs/nfs/nfs.ko
> a00000020a73ea30 nfsd 523168
> /lib/modules/2.6.27.8-1-sgidev/ke
> rnel/fs/nfsd/nfsd.ko
>
> crash> sym xfs_ioerror_alert
> a000000209992d18 (T) xfs_ioerror_alert
>
> Thanks.
> -Cliff
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
15 years, 10 months
crash mod -S problem
by Cliff Wickman
Hi Dave, and company,
I have a question. Perhaps this is a known issue -- should I be looking
in an archive somewhere?
The crash command "mod -S" is messing up the address list.
This is crash-4.0-7.6, running on ia64.
Note how the value of module symbol xfs_ioerror_alert has changed
after the mod -S.
Is this a crash problem? Or my problem? (there are several ?'s in
the mod -S output, including on the xfs module)
crash> sym xfs_ioerror_alert
a000000209955f80 (t) xfs_ioerror_alert
crash> mod -S
MODULE NAME SIZE OBJECT FILE
a0000002093fc088 scsi_transport_spi 50672 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/scsi/scsi_transport_spi.ko
mod: ioc4: last symbol is not _MODULE_END_ioc4?
a000000209412fa8 ioc4 13056 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/misc/ioc4.ko
mod: scsi_tgt: last symbol is not _MODULE_END_scsi_tgt?
a000000209435cd0 scsi_tgt 24640 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/scsi/scsi_tgt.ko
a000000209453610 sgiioc4 14656 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/ide/pci/sgiioc4.ko
mod: mptbase: last symbol is not _MODULE_END_mptbase?
a000000209497298 mptbase 166540 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/message/fusion/mptbase.ko
a0000002094f8008 scsi_mod 299024 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/scsi/scsi_mod.ko
a000000209547038 ide_core 229280 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/ide/ide-core.ko
a000000209583da0 qla1280 148256 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/scsi/qla1280.ko
mod: scsi_transport_fc: last symbol is not _MODULE_END_scsi_transport_fc?
a0000002095b51d0 scsi_transport_fc 88156 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/scsi/scsi_transport_fc.ko
a0000002095d7bd8 mptfc 32776 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/message/fusion/mptfc.ko
mod: mptscsih: last symbol is not _MODULE_END_mptscsih?
a000000209610618 mptscsih 68816 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/message/fusion/mptscsih.ko
a000000209631208 hwmon 5304 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/hwmon/hwmon.ko
mod: thermal_sys: last symbol is not _MODULE_END_thermal_sys?
a000000209655c90 thermal_sys 24656 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/thermal/thermal_sys.ko
a000000209679b40 thermal 41144 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/acpi/thermal.ko
a0000002096b4340 processor 85008 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/acpi/processor.ko
a0000002096d23c8 fan 9960 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/acpi/fan.ko
a000000209718490 mptspi 34936 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/message/fusion/mptspi.ko
a000000209730e00 ide_generic 4264 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/ide/ide-generic.ko
a0000002097506f0 crc_t10dif 2336 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/lib/crc-t10dif.ko
a000000209773430 button 14312 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/acpi/button.ko
a0000002097b1380 sd_mod 72432 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/scsi/sd_mod.ko
a0000002097e12a0 sg 71976 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/scsi/sg.ko
a0000002098124b8 cdrom 77752 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/cdrom/cdrom.ko
mod: cannot find or load object file for ide_cd_mod module
mod: libphy: last symbol is not _MODULE_END_libphy?
a000000209859928 libphy 40168 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/net/phy/libphy.ko
mod: xfs: last symbol is not _MODULE_END_xfs?
a0000002099abaf0 xfs 1233888 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/fs/xfs/xfs.ko
a0000002099ed130 mptctl 188064 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/message/fusion/mptctl.ko
a000000209a04690 mmtimer 18836 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/char/mmtimer.ko
a000000209a53a68 kdbm_pg 16632 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/kdb/modules/kdbm_pg.ko
a000000209a70a48 kdbm_sched 3296 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/kdb/modules/kdbm_sched.ko
a000000209a91b28 kdbm_task 40608 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/kdb/modules/kdbm_task.ko
a000000209b1fba0 qla2xxx 463704 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/scsi/qla2xxx/qla2xxx.ko
a000000209b850c0 tg3 284796 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/net/tg3.ko
mod: dm_mod: last symbol is not _MODULE_END_dm_mod?
a000000209ff25f8 dm_mod 143048 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/md/dm-mod.ko
a00000020a016518 kdbm_vm 28112 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/kdb/modules/kdbm_vm.ko
a00000020a031f20 mspec 16932 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/char/mspec.ko
a00000020a05e290 numatools 59232 /lib/modules/2.6.27.8-1-sgidev/up
dates/numatools.ko
a00000020a073f38 xp 17216 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/misc/sgi-xp/xp.ko
a00000020a0b4c08 gru 87288 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/misc/sgi-gru/gru.ko
a00000020a0d38e0 sgi_gpl_lib 15272 /lib/modules/2.6.27.8-1-sgidev/we
ak-updates/extra/gpl_lib/sgi-gpl-lib.ko
a00000020a115c58 myri10ge 91048 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/net/myri10ge/myri10ge.ko
mod: loop: last symbol is not _MODULE_END_loop?
a00000020a138478 loop 34788 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/block/loop.ko
mod: cannot find or load object file for nls_iso8859_1 module
a00000020a18ac80 sgi_os_lib 111192 /lib/modules/2.6.27.8-1-sgidev/we
ak-updates/extra/os_lib/sgi-os-lib.ko
mod: crypto_blkcipher: last symbol is not _MODULE_END_crypto_blkcipher?
a00000020a1a8c00 crypto_blkcipher 36848 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/crypto/crypto_blkcipher.ko
a00000020a1c6fd0 dm_crypt 29784 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/drivers/md/dm-crypt.ko
a00000020a1e4cd8 binfmt_misc 20444 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/fs/binfmt_misc.ko
a00000020a25d758 xpmem 122536 /lib/modules/2.6.27.8-1-sgidev/up
dates/xpmem.ko
a00000020a28d518 fuse 121352 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/fs/fuse/fuse.ko
mod: ipv6: last symbol is not _MODULE_END_ipv6?
a00000020a358030 ipv6 627656 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/net/ipv6/ipv6.ko
mod: sgi_xvm: last symbol is not _MODULE_END_sgi_xvm?
a00000020a41a520 sgi_xvm 704400 /lib/modules/2.6.27.8-1-sgidev/we
ak-updates/extra/xvm/sgi-xvm.ko
a00000020a46ba78 autofs4 48656 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/fs/autofs4/autofs4.ko
a00000020a482090 exportfs 8944 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/fs/exportfs/exportfs.ko
mod: auth_rpcgss: last symbol is not _MODULE_END_auth_rpcgss?
a00000020a4b3ee0 auth_rpcgss 82696 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/net/sunrpc/auth_gss/auth_rpcgss.ko
mod: nfs_acl: last symbol is not _MODULE_END_nfs_acl?
a00000020a4d17b8 nfs_acl 6648 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/fs/nfs_common/nfs_acl.ko
a00000020a5b1e88 sunrpc 472176 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/net/sunrpc/sunrpc.ko
mod: lockd: last symbol is not _MODULE_END_lockd?
a00000020a5f1e00 lockd 141416 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/fs/lockd/lockd.ko
a00000020a6aaa98 nfs 641664 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/fs/nfs/nfs.ko
a00000020a73ea30 nfsd 523168 /lib/modules/2.6.27.8-1-sgidev/ke
rnel/fs/nfsd/nfsd.ko
crash> sym xfs_ioerror_alert
a000000209992d18 (T) xfs_ioerror_alert
Thanks.
-Cliff
15 years, 10 months
Re: BISECTED: Re: source line numbers with x86_64 modules?
by Dave Anderson
----- "Eric W. Biederman" <ebiederm(a)xmission.com> wrote:
> Mike Snitzer <snitzer(a)gmail.com> writes:
>
> > [I've trimmed the wide cc distribution that was inherited when I
> > forked a different thread]
> >
> > On Mon, Jan 12, 2009 at 10:19 PM, Eric W. Biederman
> > <ebiederm(a)xmission.com> wrote:
> >> "Mike Snitzer" <snitzer(a)gmail.com> writes:
> >>>
> >>> Now if only I could fix line numbers when debugging crashes in x86_64
> >>> modules with the crash utility! :)
> >>
> >> It's a userspace problem...
> >>
> >> All of the little usability things are userspace problems.
> >>
> >> I won't claim that it is trivial because it is a userspace problem, at the same
> >> time there is no reason to wait for any kernel features to merge etc. Someone
> >> just has to scratch an itch and go fix it.
> >
> > Yes, the crash utility (userspace) is clearly having problems getting
> > line number for symbols in x86_64 modules. But I finally took some
> > time to bisect the point in the kernel where the crash utility first
> > started to fail, it appears to be:
> >
> > commit 7460ed2844ffad7141e30271c0c3da8336e66014
> > Author: john stultz <johnstul(a)us.ibm.com>
> > Date: Fri Feb 16 01:28:21 2007 -0800
> >
> > I used version 4.0-7.6 of the crash utility to test if each commit was
> > good or bad. I simply checked if ext3's module had correct line
> > number info for the ext3_get_blocks_handle symbol with: sym
> > ext3_get_blocks_handle
>
> Weird. That patch doesn't appear to affect anything in that area.
> So my stab in the dark is that there is something in vmlinux that
> crash doesn't know how to cope with.
Actually it's not a problem with the vmlinux file, but rather with kernel
module object files. The crash utility has an embedded gdb module which
is invoked as "gdb vmlinux", and to get line numbers, the crash utility
simply uses the relevant built-in gdb function to get them. And line
numbers work fine with the base kernel code from the vmlinux file.
The debuginfo data of kernel modules can be subsequently added to the
crash session by doing a gdb "add-symbol-file" command for any or all
kernel modules. But getting correct line number information for kernel
modules has been a crap-shoot in the past, depending upon architecture
and/or kernel version. For example, they don't work with 2.6.9-based
RHEL4 x86_64 kernel modules, but work fine with 2.6.18-based RHEL5 x86_64
kernels.
Looking at Mike's suspect kernel patch list, I don't see anything that
would have any relationship to the issue. Perhaps there was a build tool
change during the same timeframe?
Dave
15 years, 10 months