On Thu, 2009-09-17 at 12:55 +0000, Dave Anderson wrote:
----- "Bob Montgomery" <bob.montgomery(a)hp.com>
wrote:
> This patch allows the dis -l command to show real source line numbers
> for module code, instead of this sort of thing:
>
I haven't tested this patch or taken the time to understand it,
but I'm taking it on good faith that it solves this bug, which
has been an elephant in the room since (I believe) the 2.6.21
timeframe.
It will be nice to get some independent verification.
In the meantime, we've found a couple of other things.
1) There is a class of module routine whose info does not
show up where this version of gdb checks, and those routines
will still not show line numbers. They are:
a) routines declared with __devexit
b) routines declared with __devinit
c) routines in module_exit() MACROs
d) routines in module_init() MACROs
In our particular 2.6.29-based test kernel, we load 70 modules.
Before this patch, we had 5507 routines that would not show
line numbers (reported with "include/linux/cpumask.h: 612 instead
of the real line).
After the patch, we have only 89 routines that won't show
line numbers correctly for the above reasons. For example:
...
ffffffffa006bc22 (t) e1000_exit_module include/linux/cpumask.h: 612
ffffffffa006bc45 (t) e1000_remove include/linux/cpumask.h: 612
ffffffffa0078188 (t) sha1_generic_mod_fini include/linux/cpumask.h: 612
ffffffffa008af54 (t) bnx2_cleanup include/linux/cpumask.h: 612
ffffffffa008af66 (t) bnx2_remove_one include/linux/cpumask.h: 612
ffffffffa008afbe (t) bnx2_init_one include/linux/cpumask.h: 612
ffffffffa00b3210 (t) cciss_init_one include/linux/cpumask.h: 612
...
2) John took a look at a new version of gdb, and it appears
to have some redesign in the symbol stuff that corrects
perhaps all of this. I'll let him summarize what he found.
In the meantime, I'll be interested to hear of any other
testing of this patch.
Bob Montgomery