[ltt-dev] LTTng 2.0 on ARM

[Dave Martin]

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