All I need is the nearest symbol name and that's it. The patch was pretty
simple so it could be easily merged. It added only a few 100's of bytes on
x86 and below 1k on PPC. It would be handy to have this in a kernel rather
than require some user utility that requires I make it work in a
cross-build environment, copy the 'insmod -m' map output to my host
machine, run the user program on the system.map and the user utilities for
every boot, crash, debug cycle.
The patch is tiny and simple and I hoped to keep it that way. If I want to
dig into the system and seriously debug rather than follow a known problem
I can use xmon on PPC, kgdb or more often than not a real JTAG debugger.
How about this - we print the module beginning _and_ the EIP symbol if we
can find one. You get what you want and I get what I want (I won't even
add a line of output to get what I want).
To solve the ksyms mystery can you send me what versions of modutils, what
architecture, what distribution and anything else you think might be
useful? I'd like to know what cases this fails in.
} You follow it. The reason I'm dropping functionality is that I want the
} functionality in userspace, not because your patch in-kernel was wasting
} any resources, but because from userspace the functionality will do the
} *right* thing always without me having to check if the symbol happened
} to be right because it was exported (and still no idea why you've more
} symbols than me in ksyms for modules). Also rarely I can get away with
} just the EIP. So in short the symbol isn't going to help because I'd
} need to recheck with ksymoops anyways and I need the stack trace too
} potentially part of other modules, so I prefer to provide via the oops
} only the numeric information, but *all* of it :) to also reduce the oops
} size. If your main object is to skip the ksymoops step, then I think
} even in such case you want to go to a full complete kksymoops instead of
} the halfway approch. I think ksymoops + module oops tracking patch is
} more than enough for the bugreports (modulo dprobes/lkcd etc...). For
} developement using a true debugger to get stack traces and inspect ram
} (i.e. uml or kgdb or kdb ) is probably superior to any other oops
} functionalty anyways (so if your object is to avoid the ksymoops step
} during developement I would suggest a real debugger that will save even
} more time).
}
} I like the strict module oops tracking in particular for pre-compiled
} kernels where we don't even need to ask the user the system.map/vmlinux
} in order to debug it, and so where it would be a total loss of global
} ram resources to load in kernel ram of every machine all the symbols of
} the whole kernel and modules. Furthmore this adds a critical needed
} feature to have a chance to debug module oopses, so it's a must-have.
}
} Nevertheless adding your ksym lookup for the EIP wouldn't hurt and it
} wouldn't waste lines (columns doesn't matter near the EIP), so we could
} merge the two things together, but as said above I don't feel the need
} of it as far as ksymoops learns about resolving the eip through the
} module information now included in the oops.
}
} I updated the patch to reduce the number of lines of the oops, this is
} incremental with the previous patch.
}
} --- 2.4.19rc3aa2/kernel/module.c.~1~ Sat Jul 27 00:48:38 2002
} +++ 2.4.19rc3aa2/kernel/module.c Sat Jul 27 03:44:16 2002
} @@ -1271,26 +1271,29 @@ static void __module_oops_tracking_print
}
} for (mod = module_list; mod != &kernel_module; mod = mod->next) {
} if (!nr--)
} - printk(" [(%s:<%p>:<%p>)]\n",
} + printk(" [(%s:<%p>:<%p>)]",
} mod->name,
} (char *) mod + mod->size_of_struct,
} (char *) mod + mod->size);
} }
} -
} }
}
} void module_oops_tracking_print(void)
} {
} int nr;
} + int i = 0;
}
} - printk("Module Oops Tracking:\n");
} + printk("Modules:");
} nr = find_first_bit(module_oops_tracking, MODULE_OOPS_TRACKING_NR_BITS);
} for (;;) {
} if (nr == MODULE_OOPS_TRACKING_NR_BITS)
} - return;
} + break;
} + if (i && !(i++ % 2))
} + printk("\n ");
} __module_oops_tracking_print(nr);
} nr = find_next_bit(module_oops_tracking, MODULE_OOPS_TRACKING_NR_BITS, nr+1);
} }
} + printk("\n");
} }
}
} #else /* CONFIG_MODULES */
}
}
} Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:26 EST