[PATCH] Support cpu_map/cpu_mask changes in 2.6.29
by Michael Holzheu
Hi Dave,
I found some time to fix the cpu_map issue in 2.6.29.
Here my proposal:
From: Michael Holzheu <holzheu(a)linux.vnet.ibm.com>
In Linux 2.6.29 the cpu_(online, possible, present, active)_map global variables
have been moved to cpu_(...)_mask variables that are pointers to structures
with bitmaps now. This patch allows crash to work with the new variables.
Note: The cpu_map_size() function now only uses STRUCT_SIZE("cpumask_t")
to get the size of the cpu map. I removed the get_symbol_type() call
since STRUCT_SIZE("cpumask_t") should always work.
Correct me if I am wrong here!
Signed-off-by: Michael Holzheu <holzheu(a)linux.vnet.ibm.com>
---
defs.h | 1
kernel.c | 111 ++++++++++++++++++++++++++++++++++++++++++------------------
ppc64.c | 4 +-
s390.c | 3 +
s390x.c | 3 +
xen_hyper.c | 2 -
6 files changed, 86 insertions(+), 38 deletions(-)
Index: crash-4.0-8.9/defs.h
===================================================================
--- crash-4.0-8.9.orig/defs.h
+++ crash-4.0-8.9/defs.h
@@ -3647,6 +3647,7 @@ int in_cpu_map(int, int);
void paravirt_init(void);
void print_stack_text_syms(struct bt_info *, ulong, ulong);
void back_trace(struct bt_info *);
+ulong cpu_map_addr(const char *type);
#define BT_RAW (0x1ULL)
#define BT_SYMBOLIC_ARGS (0x2ULL)
#define BT_FULL (0x4ULL)
Index: crash-4.0-8.9/kernel.c
===================================================================
--- crash-4.0-8.9.orig/kernel.c
+++ crash-4.0-8.9/kernel.c
@@ -533,6 +533,65 @@ kernel_init()
}
/*
+ * Get cpu map (possible, online, etc.) address from cpu mask (since 2.6.29)
+ */
+static ulong
+get_cpu_map_addr_from_mask(const char *type)
+{
+ ulong cpu_mask_addr, cpu_map_addr;
+ char cpu_mask_symbol[32];
+ char *cpu_mask_buf;
+ int cpu_mask_size;
+
+ sprintf(cpu_mask_symbol, "cpu_%s_mask", type);
+
+ if (!symbol_exists(cpu_mask_symbol))
+ return 0;
+
+ cpu_mask_addr = symbol_value(cpu_mask_symbol);
+ cpu_mask_size = STRUCT_SIZE("cpumask");
+ cpu_mask_buf = malloc(cpu_mask_size);
+ if (!cpu_mask_buf)
+ error(FATAL, "get_cpu_map_addr_from_mask: out of memory\n");
+ readmem(cpu_mask_addr, KVADDR, cpu_mask_buf, cpu_mask_size,
+ cpu_mask_symbol, FAULT_ON_ERROR);
+ cpu_map_addr = ULONG(cpu_mask_buf + MEMBER_OFFSET("cpumask", "bits"));
+ free(cpu_mask_buf);
+
+ return cpu_map_addr;
+}
+
+/*
+ * Get cpu map address. Types are: possible, online, present and active
+ */
+ulong
+cpu_map_addr(const char *type)
+{
+ char cpu_map_symbol[32];
+
+ sprintf(cpu_map_symbol, "cpu_%s_map", type);
+ if (symbol_exists(cpu_map_symbol))
+ return symbol_value(cpu_map_symbol);
+ else
+ return get_cpu_map_addr_from_mask(type);
+}
+
+/*
+ * Get cpu map (possible, online, etc.) size
+ */
+static int
+cpu_map_size(void)
+{
+ int len;
+
+ len = STRUCT_SIZE("cpumask_t");
+ if (len < 0)
+ return sizeof(ulong);
+ else
+ return len;
+}
+
+/*
* If the cpu_present_map, cpu_online_map and cpu_possible_maps exist,
* set up the kt->cpu_flags[NR_CPUS] with their settings.
*/
@@ -546,9 +605,9 @@ cpu_maps_init(void)
ulong cpu_flag;
char *name;
} mapinfo[] = {
- { POSSIBLE, "cpu_possible_map" },
- { PRESENT, "cpu_present_map" },
- { ONLINE, "cpu_online_map" },
+ { POSSIBLE, "possible" },
+ { PRESENT, "present" },
+ { ONLINE, "online" },
};
if ((len = STRUCT_SIZE("cpumask_t")) < 0)
@@ -557,12 +616,13 @@ cpu_maps_init(void)
buf = GETBUF(len);
for (m = 0; m < sizeof(mapinfo)/sizeof(struct mapinfo); m++) {
- if (!kernel_symbol_exists(mapinfo[m].name))
+ if (!cpu_map_addr(mapinfo[m].name))
continue;
- if (!readmem(symbol_value(mapinfo[m].name), KVADDR, buf, len,
+ if (!readmem(cpu_map_addr(mapinfo[m].name), KVADDR, buf, len,
mapinfo[m].name, RETURN_ON_ERROR)) {
- error(WARNING, "cannot read %s\n", mapinfo[m].name);
+ error(WARNING, "cannot read cpu_%s_map\n",
+ mapinfo[m].name);
continue;
}
@@ -578,7 +638,7 @@ cpu_maps_init(void)
}
if (CRASHDEBUG(1)) {
- fprintf(fp, "%s: ", mapinfo[m].name);
+ fprintf(fp, "cpu_%s_map: ", mapinfo[m].name);
for (i = 0; i < NR_CPUS; i++) {
if (kt->cpu_flags[i] & mapinfo[m].cpu_flag)
fprintf(fp, "%d ", i);
@@ -605,21 +665,21 @@ in_cpu_map(int map, int cpu)
switch (map)
{
case POSSIBLE:
- if (!kernel_symbol_exists("cpu_possible_map")) {
+ if (!cpu_map_addr("possible")) {
error(INFO, "cpu_possible_map does not exist\n");
return FALSE;
}
return (kt->cpu_flags[cpu] & POSSIBLE);
case PRESENT:
- if (!kernel_symbol_exists("cpu_present_map")) {
+ if (!cpu_map_addr("present")) {
error(INFO, "cpu_present_map does not exist\n");
return FALSE;
}
return (kt->cpu_flags[cpu] & PRESENT);
case ONLINE:
- if (!kernel_symbol_exists("cpu_online_map")) {
+ if (!cpu_map_addr("online")) {
error(INFO, "cpu_online_map does not exist\n");
return FALSE;
}
@@ -4187,7 +4247,7 @@ dump_kernel_table(int verbose)
}
fprintf(fp, "\n");
fprintf(fp, " cpu_possible_map: ");
- if (kernel_symbol_exists("cpu_possible_map")) {
+ if (cpu_map_addr("possible")) {
for (i = 0; i < nr_cpus; i++) {
if (kt->cpu_flags[i] & POSSIBLE)
fprintf(fp, "%d ", i);
@@ -4196,7 +4256,7 @@ dump_kernel_table(int verbose)
} else
fprintf(fp, "(does not exist)\n");
fprintf(fp, " cpu_present_map: ");
- if (kernel_symbol_exists("cpu_present_map")) {
+ if (cpu_map_addr("present")) {
for (i = 0; i < nr_cpus; i++) {
if (kt->cpu_flags[i] & PRESENT)
fprintf(fp, "%d ", i);
@@ -4205,7 +4265,7 @@ dump_kernel_table(int verbose)
} else
fprintf(fp, "(does not exist)\n");
fprintf(fp, " cpu_online_map: ");
- if (kernel_symbol_exists("cpu_online_map")) {
+ if (cpu_map_addr("online")) {
for (i = 0; i < nr_cpus; i++) {
if (kt->cpu_flags[i] & ONLINE)
fprintf(fp, "%d ", i);
@@ -5927,20 +5987,15 @@ get_cpus_online()
char *buf;
ulong *maskptr;
- if (!symbol_exists("cpu_online_map"))
+ if (!cpu_map_addr("online"))
return 0;
- if (LKCD_KERNTYPES()) {
- if ((len = STRUCT_SIZE("cpumask_t")) < 0)
- error(FATAL, "cannot determine type cpumask_t\n");
- } else
- len = get_symbol_type("cpu_online_map", NULL, &req) ==
- TYPE_CODE_UNDEF ? sizeof(ulong) : req.length;
+ len = cpu_map_size();
buf = GETBUF(len);
online = 0;
- if (readmem(symbol_value("cpu_online_map"), KVADDR, buf, len,
+ if (readmem(cpu_map_addr("online"), KVADDR, buf, len,
"cpu_online_map", RETURN_ON_ERROR)) {
maskptr = (ulong *)buf;
@@ -5969,12 +6024,7 @@ get_cpus_present()
if (!symbol_exists("cpu_present_map"))
return 0;
- if (LKCD_KERNTYPES()) {
- if ((len = STRUCT_SIZE("cpumask_t")) < 0)
- error(FATAL, "cannot determine type cpumask_t\n");
- } else
- len = get_symbol_type("cpu_present_map", NULL, &req) ==
- TYPE_CODE_UNDEF ? sizeof(ulong) : req.length;
+ len = cpu_map_size();
buf = GETBUF(len);
present = 0;
@@ -6008,12 +6058,7 @@ get_cpus_possible()
if (!symbol_exists("cpu_possible_map"))
return 0;
- if (LKCD_KERNTYPES()) {
- if ((len = STRUCT_SIZE("cpumask_t")) < 0)
- error(FATAL, "cannot determine type cpumask_t\n");
- } else
- len = get_symbol_type("cpu_possible_map", NULL, &req) ==
- TYPE_CODE_UNDEF ? sizeof(ulong) : req.length;
+ len = cpu_map_size();
buf = GETBUF(len);
possible = 0;
Index: crash-4.0-8.9/s390.c
===================================================================
--- crash-4.0-8.9.orig/s390.c
+++ crash-4.0-8.9/s390.c
@@ -1001,7 +1001,8 @@ s390_get_smp_cpus(void)
{
unsigned long map = 0, addr;
int i, cpu_num = 0;
- addr=symbol_value("cpu_online_map");
+
+ addr = cpu_map_addr("online");
readmem(addr, KVADDR, &map,sizeof(long), "cpu_online_map",FAULT_ON_ERROR);
for(i = 0; i < sizeof(map)*8;i++){
if(map & 0x1UL)
Index: crash-4.0-8.9/s390x.c
===================================================================
--- crash-4.0-8.9.orig/s390x.c
+++ crash-4.0-8.9/s390x.c
@@ -1031,7 +1031,8 @@ s390x_get_smp_cpus(void)
{
unsigned long map = 0, addr;
int i, cpu_num = 0;
- addr=symbol_value("cpu_online_map");
+
+ addr = cpu_map_addr("online");
readmem(addr, KVADDR, &map,sizeof(long), "cpu_online_map",FAULT_ON_ERROR);
for(i = 0; i < sizeof(map)*8;i++){
if(map & 0x1UL)
Index: crash-4.0-8.9/ppc64.c
===================================================================
--- crash-4.0-8.9.orig/ppc64.c
+++ crash-4.0-8.9/ppc64.c
@@ -2407,9 +2407,9 @@ ppc64_paca_init(void)
if (!symbol_exists("paca"))
error(FATAL, "PPC64: Could not find 'paca' symbol\n");
- if (symbol_exists("cpu_present_map"))
+ if (cpu_map_addr("present"))
map = PRESENT;
- else if (symbol_exists("cpu_online_map"))
+ else if (cpu_map_addr("online"))
map = ONLINE;
else
error(FATAL,
Index: crash-4.0-8.9/xen_hyper.c
===================================================================
--- crash-4.0-8.9.orig/xen_hyper.c
+++ crash-4.0-8.9/xen_hyper.c
@@ -1815,7 +1815,7 @@ xen_hyper_get_cpu_info(void)
error(FATAL, "cannot malloc cpumask space.\n");
}
/* kakuma: It may be better to use cpu_present_map. */
- addr = symbol_value("cpu_online_map");
+ addr = cpu_map_addr("online");
if (!readmem(addr, KVADDR, xht->cpumask,
XEN_HYPER_SIZE(cpumask_t), "cpu_online_map", RETURN_ON_ERROR)) {
error(FATAL, "cannot read cpu_online_map.\n");
15 years, 5 months
Re: [Crash-utility] mod -S and debuginfo kernel rpm
by Dave Anderson
----- "Guy Streeter" <streeter(a)redhat.com> wrote:
> > Guy -- are you on board with this?
>
> This looks good to me.
> In our automated setup environment we always create a script in the
> same dir as the vmcore that will start crash with the right vmcore and
> vmlinux filenames on the commandline. It would be really cool if we
> could specify the module search prefix there as well, so "mod -S" would
> "just work". Being able to use "mod -S ." is enough, though.
Fair enough -- it's easy enough to add a new command line option
to specify the target module directory. I'll do that.
Just curious though, why not have a single modules-tree location for
each kernel release instead of duplicating the trees for every
vmlinux/vmcore instantiation?
Dave
15 years, 5 months
Re: [Crash-utility] mod -S and debuginfo kernel rpm
by Dave Anderson
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> wrote:
> > So there would be that restriction as to the *relative* locations of
> > the .ko and .ko.debug files. But I don't think that's really all that
> > burdensome.
> >
> > Comments?
>
> I think that's a good proposal!
>
> Michael
OK, so here's the proposal:
- Make the currently-existing "mod -S <release-dir>" command find both the
stripped "<module>.ko" and its associated "<module.ko.debug>"
Prerequisite:
- Both the "<module>.ko" and "<module.ko.debug>" files must be located in
or under the <release-dir>.
The search mechanism for the stripped "<module>.ko" file would be:
- Search the complete <release-dir> tree for "<module>.ko".
. When found, save the relative directory pathname containing the file,
where the <relative-dir-path> would be rooted from <release-dir>.
The search mechanism for the associated "<module>.ko.debug" file would be
done in this order:
1. Search the <release-dir>/<relative-dir-path> directory
2. Search the <release-dir>/<relative-dir-path>/.debug directory
3. Search the <release-dir>/usr/lib/debug/<relative-dir-path> directory
This scheme would allow an alternate module/module-debuginfo setup to
be done like so:
$ mkdir <release-dir>
$ cd <release-dir>
$ rpm2cpio kernel-<release>.rpm | cpio -idv
$ rpm2cpio kernel-debuginfo-<release>.rpm | cpio -idv
And then the modules and their debuginfo data could be loaded using
the current alternative mechanism:
crash> mod -S <release-dir>
Also, because of the 1-2-3 debuginfo search order above, this would allow
the copying of "<module>.ko" and "<module>.ko.debug" files into the same
directory anywhere underneath <target-dir>, or in the ".debug" subdirectory
of the directory containing "<module>.ko".
That being the case, it would be easy to handle per-release oddities such
as the RHEL /lib/modules/<release>/updates directory, by simply copying the
associated <module>.ko.debug file into the same directory as its stripped file.
Guy -- are you on board with this?
Dave
15 years, 5 months
Re: [Crash-utility] mod -S and debuginfo kernel rpm
by Dave Anderson
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> wrote:
>
> I thought that you where suggesting to search only in
> <-S dir>/lib/modules.. and <-S dir>/usr/lib/debug/..
>
> As I said before, "mod -S <dir>" currently searches in all
> subdirectories of <dir>.
Right, that's what my follow-up email explained more thoroughly:
> And just to clarify this further. When "mod -S [directory]" is entered,
> the search will be made starting from [directory]. In other words,
> it will not immediately append "/lib/modules" and "/usr/lib/debug/lib/modules"
> onto [directory]. It's just that that's where they'll be found
> if the double-rpm2cpio were done.
>
> Conceivably you could just dump all the .ko and .ko.debug files into
> the one flat [directory], and it will find them right away.
But that leads to another issue.
Suppose a directory target was set up with double-rpm2cpio, such that,
for example, the ext3.ko module would be found here:
<target-dir>/lib/modules/2.6.18-128.el5/kernel/fs/ext3/ext3.ko
The gdb algorithm currently searches for ext3.ko.debug in these 3
directories, in this order:
A. <target-dir>/lib/modules/2.6.18-128.el5/kernel/fs/ext3
B. <target-dir>/lib/modules/2.6.18-128.el5/kernel/fs/ext3/.debug
C. /usr/lib/debug/lib/modules/2.6.18-128.el5/kernel/fs/ext3
So it doesn't find it in the "double-rpm2cpio" layout. And so my
proposal would add this additional search path:
D. <target-dir>/usr/lib/debug/lib/modules/2.6.18-128.el5/kernel/fs/ext3
and it would find it. It's essentially "C", but with <target-dir>
prepended to the search path.
But it *does* require an analogous relative file tree layout.
So if for example, all .ko and .ko.debug files were just dumped in
the <target-dir>:
(1) ext3.ko would be found in <target-dir>
(2) ext3.ko.debug would be found in <target-dir> -- using gdb algorithm "A".
But if ext3.ko was located in:
<target-dir>/lib/modules/2.6.18-128.el5/kernel/fs/ext3
then the proposed "D" algorithm would find ext3.ko.debug in:
<target-dir>/usr/lib/debug/lib/modules/2.6.18-128.el5/kernel/fs/ext3
But it would *only* find it in the directory above. And that's because
the gdb algorithms create fully-qualified directory pathnames based
upon the full path to the stripped .ko file, and then looks in those
directories to accomplish "A", "B" and "C".
So there would be that restriction as to the *relative* locations of
the .ko and .ko.debug files. But I don't think that's really all that
burdensome.
Comments?
Dave
15 years, 5 months
Re: [Crash-utility] mod -S and debuginfo kernel rpm
by Dave Anderson
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> wrote:
> > So for example, if the target "mod -S [directory]" was specified to be ".",
> > there would be "./lib/modules" and "./usr/lib/debug/lib/modules" subdirectory
> > trees.
> >
> > And then "mod -S [directory]" would just work.
>
> Doesn't this change the current behavior? Currently the search is
> restricted to the directory specified with mod -S. You would change that
> and search only <-S dir>/lib/modules.. and <-S dir>/usr/lib/debug/..> ?
It doesn't change the current behavior, but rather enhances it to
also make the search for the associated ko.debug files in the same
subdirectory tree.
The current behavior of "mod -S [directory]" is to restrict the search
for the stripped .ko files to the specified directory. But then if
the "found" stripped .ko file is linked to a .ko.debug file, then
the standard gdb rules are applied for finding the associated ko.debug
files, i.e., in that same directory where the stripped .ko file
exists, in a .debug subdirectory there, or finally, in the global
/usr/lib/debug/lib/modules/<release>/... tree.
Sorry if I keep repeating myself...
>
> So maybe a new prefix option (-P ?) might be better:
>
> (4) Search stripped modules in <-P dir>/lib/modules/ and debug modules
> in <-P dir>/usr/lib/debug/lib/modules/
We already have the "Search stripped modules in <-P dir>/lib/modules"
capability in place. That's "mod -S [dir]" as it works now.
The question is whether it makes sense to restrict the location
of the associated debuginfo tree to the same root directory as
the "mod -S [dir]" directory.
So when you stated:
> That's what I used. In particular I did the following:
>
> # mkdir mydump
> # cd mydump
> # rpm2cpio kernel-2.6.18-128.el5.s390x.rpm | cpio -idv
> # rpm2cpio kernel-debuginfo-2.6.18-128.el5.s390x.rpm | cpio -idv
>
> Then I called:
>
> # mod -S lib/modules/2.6.18-128.el5/
>
> That only loads the stripped modules. It does not search locally.
My suggestion would allow you to do this:
# mkdir mydump
# cd mydump
# rpm2cpio kernel-2.6.18-128.el5.s390x.rpm | cpio -idv
# rpm2cpio kernel-debuginfo-2.6.18-128.el5.s390x.rpm | cpio -idv
# crash
...
crash> mod -S .
and then the stripped modules would be searched for in:
./lib/modules/...
And then my proposed enhancement would search for the associated
ko.debug files in:
./usr/lib/debug/lib/modules/...
So no changes to the current "mod" command options would be required.
And taking Guy's request, where a central machine may be dedicated
to storing dumpfiles, they could to the "double-rpm2cpio" in a
static location, with one "double-tree" per kernel release. With
that in place, the would always have the double-tree in place,
and then could run:
crash> mod -S <path-to>/<release-double-tree>
Seems pretty straight forward to me. And as always, I'm just
trying to keep things as simple as possible.
The question is whether you are suggesting that it would be
common to have the /lib/modules tree rooted in one location,
and the /usr/lib/debug/lib/modules tree rooted elsewhere.
Is that what you're saying?
Dave
15 years, 5 months
Re: [Crash-utility] mod -S and debuginfo kernel rpm
by Dave Anderson
----- "Guy Streeter" <streeter(a)redhat.com> wrote:
> Dave Anderson wrote:
> ...
> >
> > In other words, are you suggesting that there would be
> > "./lib" and "./usr" subdirectories in your current directory?
> > Where the base modules would live under "./lib" and the
> > debug modules would live under "./usr"? (like Michael's setup)
> >
> > That would be best -- it would do-able to just enhance the currently-
> > existing "mod -S [directory]" option to do the right thing automatically
> > when dealing with split dumpfiles.
> >
> > I just want to get everybody on the same page.
> >
>
> We can set up the directories however we need to. It's automated, so the
> labor involved is not an issue. The result we want is to be able to do
> symbolic debugging in loadable modules when the target kernel and
> debuginfo packages are not "installed" on the system.
Right -- I understand. I wasn't sure if that automated CAS system you guys
use already did something with the kernel-debuginfo rpm -- but not with the
kernel rpm which contains the stripped modules. Crash needs them both.
Again, crash searches for the stripped module first, and then looks for the
associated .debug piece either in:
(1) the same directory containing the stripped module, or
(2) the .debug subdirectory in the same directory containing the stripped module, or
(3) by prepending "/usr/lib/debug" onto the directory containing the stripped module
And for the proposed plan to work, option (3) would be used, i.e., where there
would be "parallel" trees rooted from the same target directory.
> It would help also if this would "just work", either because the current
> directory is searched or because crash could be invoked with an option
> or env var that pointed to the location.
I'd prefer to keep the current mechanism in place, where you can
specify a target directory to "mod -S [directory]".
The parallel tree layout would have to be equivalent as is the case when
both the kernel and kernel-debuginfo rpms were installed natively, but with
a directory pre-pended onto the /lib/... and /usr/... directories. (which
could simply be ".")
So for example, if the target "mod -S [directory]" was specified to be ".",
there would be "./lib/modules" and "./usr/lib/debug/lib/modules" subdirectory
trees.
And then "mod -S [directory]" would just work.
Have I made myself clear? ;-)
If that's not the case, let me know...
Thanks,
Dave
15 years, 5 months
Re: [Crash-utility] mod -S and debuginfo kernel rpm
by Dave Anderson
----- "Dave Anderson" <anderson(a)redhat.com> wrote:
> ----- "Guy Streeter" <streeter(a)redhat.com> wrote:
>
> > Dave Anderson wrote:
> > ...
> > How difficult would it be to support one user-specified prefix string,
> > or at least look in "./" as well as "/"? This would help a lot with the
> > systems we set up specifically for core analysis. We really don't want
> > to install the debuginfo rpms for every kernel we might need to look at
> > Updating the system tends to wipe them all out, and iirc they over-write
> > some of each other's files.
>
> Right -- see my last email that I just sent before seeing yours.
> You already can specify an alternative for the stripped module
> directory starting path, but I don't believe it will find the
> associated .ko.debug file.
>
> So we're talking about two different scenarios:
>
> (1) Michael has both the /lib/modules/... and /usr/lib/debug/lib/modules/...
> trees dumped in his current directory, and
> (2) I believe you're specifying that only /usr/lib/debug/lib/modules/...
> tree would be in your current directory.
>
> But with (2), the base stripped module directory starting path still
> needs to be there (someplace).
Guy,
Just to clarify...
In other words, are you suggesting that there would be
"./lib" and "./usr" subdirectories in your current directory?
Where the base modules would live under "./lib" and the
debug modules would live under "./usr"? (like Michael's setup)
That would be best -- it would do-able to just enhance the currently-
existing "mod -S [directory]" option to do the right thing automatically
when dealing with split dumpfiles.
I just want to get everybody on the same page.
Dave
15 years, 5 months
Re: [Crash-utility] mod -S and debuginfo kernel rpm
by Dave Anderson
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> wrote:
> > That is by intention. The argument to the "mod" command should be
> > the stripped "<module_name>.ko" file. When loading that file, the
> > embedded link to the "<module_name>.ko.debug" file found in the
> > stripped "<module_name>.ko" file should be recognized and handled
> > internally by the embedded gdb module.
>
> From where gets gdb this link? Is it somewhere stored in the ELF module
> file?
There is the .gnu_debuglink section in the module that contains just the name
of the associated .ko.debug file along with a CRC value to ensure it's the correct
one after it finds it:
$ objump -s /lib/modules/2.6.18-128.el5/kernel/fs/ext3/ext3.ko
... [ snip ] ...
Contents of section .gnu_debuglink:
0000 65787433 2e6b6f2e 64656275 67000000 ext3.ko.debug...
0010 5392d21a
$
And then gdb takes it from there. The embedded version of gdb (gdb-6.1)
inside crash looks for the associated ext3.ko.debug file in 3 directories,
based upon first creating a fully-qualified path to the directory
containing the stripped module files:
(1) in the same directory containing the stripped module
(2) in the .debug subdirectory of the directory containing the stripped module
(3) in /usr/lib/debug/<path-to-module-directory>
And so normally it finds the associated .ko.debug file in
/usr/lib/debug/lib/modules/<release>/<path-to-module-directory>.
>
> What I want to do is to unpack the kernel rpm and kernel debuginfo rpm
> to my local directory and then load the modules with "mod -S"
> In my local directory I have lib/modules/2.6.18-128.el5/ with the kernel
> modules and usr/lib/debug/lib/modules/2.6.18-128.el5/ with the .debug files.
>
> When I use "mod -S lib/modules/2.6.18-128.el5" the debug information
> seems not to be loaded.
With "mod -S", it will use the fully qualified pathname to the stripped module
as the starting point, i.e., /lib/modules/<release>/<path-to-module-directory>.
It will look in that directory, in the .debug subdirectory in that directory,
and finally in /usr/lib/debug/lib/modules/<release>/<path-to-module-directory>.
In your case, crash has no idea where you put the modules, so you would have
to manually specify where each of the stripped modules are located with
"mod -s <module> <your/directory/path/stripped-module-name>, and then put the
associated .ko.debug in the same directory as each stripped module.
Any other behaviour such as what you're expecting would require a patch
to kernel.c:module_objfile_search(), at the very bottom of the function
just prior to it returning with a retbuf of NULL (which is what's happening
to you now). But even there, it would find the stripped module, but the
gdb mechanism for finding the associated .ko.debug file would fail unless
you manually moved the .ko.debug files into the same directory where their
associated stripped module is located.
Dave
15 years, 5 months
Re: [Crash-utility] cpu online map changes in 2.6.29
by Dave Anderson
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> wrote:
> Hi all,
>
> Currently crash does not work with 2.6.29 kernels, because of changes in
> the cpu_online_map code:
>
> crash 4.0-8.9
> Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Red
> Hat,
> Inc.
> ...
> crash: cannot resolve "cpu_online_map"
>
> Is anybody working on that issue?
>
> Michael
Not that I'm aware of -- you volunteering?
Looks like all 3 cpu_xxx_map references (online, present and possible)
that crash potentially uses need to be able to recognize and handle the
need to access them via their cpu_xxx_mask variables. And as always,
to maintain backwards-compatibility, i.e., to recognize when neither
cpu_xxx_map and cpu_xxx_mask exist, such as in really older kernels...
Let us know if you can undertake the task.
Dave
15 years, 5 months
Re: [Crash-utility] mod -S and debuginfo kernel rpm
by Dave Anderson
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> wrote:
> Hi,
>
> The kernel debuginfo rpms (e.g. kernel-debuginfo-xxx.s390x.rpm) > provide
> kernel modules that contain debug sections in order to access the > data
> structures with tools like crash. The kernel modules are named "<module_name>.ko.debug".
>
> The mod -S command in crash does not recognize the ".debug" files. Is
> that by intention? What is the recommended way to load all the debug
> information?
That is by intention. The argument to the "mod" command should be
the stripped "<module_name>.ko" file. When loading that file, the
embedded link to the "<module_name>.ko.debug" file found in the
stripped "<module_name>.ko" file should be recognized and handled
internally by the embedded gdb module.
Note that the "OBJECT FILE" name shown by "mod -S" command shows
the object file found in the "/lib/modules/...", i.e., not the
associated debuginfo file typicall found in "/usr/lib/debug/lib/modules/...".
> Michael
15 years, 5 months