lkml.org 
[lkml]   [2003]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] fix for kallsyms module symbol resolution problem
From
Date
On Sun, 2003-06-29 at 21:06, Rusty Russell wrote:
> Please test, because that's only one problem.
>
> The other is that the module_text_address() returns true if the value
> is within the module, *not* just if it's within a function. So you
> can get some noise there, too, on archs which don't do real
> backtracing.

Well, the fix is pretty cast iron in that it will print out the closest
symbol with a non null name (which has got to be better than printing an
empty string). The routine length may still be wrong since the next
closest symbol may still be null.

However, that does bring me to another issue we have on parisc (the
problem traceback was actually from x86): our tool chain, for reasons
best known to itself, inserts local symbol names into the symbol table
section. On parisc, we get rid of them again by throwing them out of
the symbol table section in module_finalize (which we shouldn't do,
since the pointers are constant).

Perhaps there should be a per-arch hook for purging the symbol tables of
irrelevant symbols before we do kallsyms lookups in it?

James


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.047 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site