On Wed, Sep 14, 2011 at 05:27:08PM +0100, Jon Medhurst (Tixy) wrote: > On Wed, 2011-09-14 at 11:09 +0100, Dave Martin wrote: > > On Tue, Sep 13, 2011 at 11:14:47PM +0530, Rabin Vincent wrote: > [...] > > > The problem is that the addresses returned by kallsyms_lookup_name() > > > does not have the zero bit, which is what is expected for Thumb > > > functions because the BLX instruction which is used to call them uses > > > this bit to determines which mode to switch into. Since it's cleared, > > > you switch to ARM mode and attempt to execute Thumb-2 code, with obvious > > > results. > > > > > > A cursory look at the parties involved shows that nm doesn't show the > > > zero bit (even though it's set in the vmlinux symbol table), and > > > scripts/kallsyms builds the table by parsing nm's output. > > > > It's not quite as simple as saying "the output of nm is wrong" though... > > > > When getting the address of a function, there are actually two > > separate answers: > > > > a) the pointer which can be used to call the function > > > > b) the address of the start of the function body > > > > On many arches these they are identical, but on some they are different. > > On ARM, they are identical for ARM code but different for Thumb code > > (because the Thumb bit must be set in case (a) but not in case (b)) > > > > It may be worth looking at what is done in the kernel for ia64 and ppc64. > > I believe that (a) and (b) are quite different for these because > > functions are called through descriptors. Don't quote me on that though: > > I'm mostly ignorant about these arches. > > > > For the Thumb-2 kernel case, we can probably hack around this: there > > are various places in the kernel where we just force-set the Thumb bit > > in addresses without really knowing what the target code is. We get > > away with this because the kernel is (very nearly) 100% Thumb code > > for a Thumb-2 kernel. > > > > However, if the kernel already has a correct approach for solving this > > problem, we should probably be using it. > > This is the same issue I found recently with kprobes [1]. There is also > an inconsistency as function symbols in loadable module do have bit zero > set, but if the module is built-in then bit zero is clear.
Does that mean that some different infrastructure is used to get the module symbols compared with kallsyms? That feels nasty -- they should at least be consistent... ---Dave _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
