From mboxrd@z Thu Jan 1 00:00:00 1970 From: jon.medhurst@linaro.org (Jon Medhurst (Tixy)) Date: Wed, 14 Sep 2011 17:27:08 +0100 Subject: [ltt-dev] LTTng 2.0 on ARM In-Reply-To: <20110914100931.GB2104@arm.com> References: <4E68559A.8080204@linaro.org> <4E6E4250.2000309@linaro.org> <4E6F3B93.5050603@linaro.org> <20110914100931.GB2104@arm.com> Message-ID: <1316017628.2576.44.camel@linaro1> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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