[ltt-dev] LTTng 2.0 on ARM
Jon Medhurst (Tixy)
jon.medhurst at linaro.org
Wed Sep 14 12:27:08 EDT 2011
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.
--
Tixy
[1] http://www.spinics.net/lists/arm-kernel/msg138283.html
More information about the linux-arm-kernel
mailing list