[Pkg-kde-extras] Bug#728869: gammaray FTBFS: build failed on post-compile-test on mips/mipsel

[Dejan Latinovic]

Package: gammaray
Version: 1.2.2-1
Severity: serious
Tags: jessie sid
Justification: FTBFS

In an attempt to rebuild the package on mips/mipsel, build failed on testing:

< Running tests...
< /usr/bin/ctest --force-new-ctest-process -j6
< Test project /build/buildd2-gammaray_1.2.2-1-mips-r9OCsw/gammaray-1.2.2/obj-mips-linux-gnu
<     Start 1: connectiontest-preload
<     Start 2: connectiontest-style
<     Start 3: connectiontest-gdb
<     Start 4: attachtest-gdb
< 1/4 Test #1: connectiontest-preload ...........***Failed    2.43 sec
< Failed to launch injector preload
< Exit code: 1
< Error: Symbol is not marked as relocatable: qt_startup_hook
< 
< 2/4 Test #2: connectiontest-style .............   Passed    6.98 sec
< 3/4 Test #3: connectiontest-gdb ...............   Passed   13.83 sec
< 4/4 Test #4: attachtest-gdb ...................   Passed   33.19 sec
< 
< 75% tests passed, 1 tests failed out of 4
< 
< Total Test time (real) =  33.30 sec
< 
< The following tests FAILED:
< 	  1 - connectiontest-preload (Failed)


The full build logs are available from:
https://buildd.debian.org/status/fetch.php?pkg=gammaray&arch=mips&ver=1.2.2-1&stamp=1356200075
https://buildd.debian.org/status/fetch.php?pkg=gammaray&arch=mipsel&ver=1.2.2-1&stamp=1356200317



GammaRay uses preloading to overwrite specific function calls in QtCore to
hook into its target application.

To be sure that the overwriting for qt_startup_hook will work,
test connectiontest-preload with readelf --relocs --wide checks if sybmbol
qt_startup_hook is marked as relocatable with JUMP_SLOT relocation, which
means that symbol will be resolved by dynamic linker and called at run
time through the plt.

The problem for Mips is that it has, besides the plt, another method of
calling functions from .so files, and this method doesn't need JUMP_SLOT
relocations (in fact, it doesn't need any relocations). This method uses .got
entries and lazy binding stubs. For example, if we call printf function, the
typical code is (gp register here points at the .got section):

lw t9, offset(gp)   // load in t9 function pointer from the address gp + offset
jalr t9             // call the function in t9

Initially, the memory at gp + offset will contain the address of the lazy
binding stub for printf. Lazy binding stubs look like:

lw      t9, 0(gp)
move    t7,ra
li      t8,7
jalr    t9

First instruction loads in t9 the address of the function _dl_runtime_resolve
from the predefined place in .got (it is located in first .got entry).
_dl_runtime_resolve is dynamic linker's function which resolves calls to
functions from .so files (printf in this case). Second and third instructions
load registers t7 and t8 with arguments that _dl_runtime_resolve needs. The key
argument here is 7 - it is dynamic symbol table index of printf, so that dynamic
linker knows which function to search for. Last instruction calls
_dl_runtime_resolve. After _dl_runtime_resolve finds printf in some .so file, it
will overwrite the .got entry for printf with found printf address, so that next
calls to printf will not go through lazy binding stub, but directly call printf.

All this doesn't need any relocations (below will be explained why). There is a
method how it can be determined whether a call to function will go through .got
and lazy binding stub.

First, Mips ABI specifies that .got is divided in two parts - local and global.
Dynamic linker only resolves symbols from the global part of the .got (that is,
only symbols from global part of the .got have lazy binding stubs. Entries from
the local part of the .got are filled with final values during static linking).
Mips ABI also specifies that the order of symbols in global part of the .got
must match the order of symbols in dynamic symbol table. In the .dynamic section
(obtained with "readelf -d" command), there is a Mips-specific dynamic tag
DT_MIPS_GOTSYM which gives the dynamic symbol index of the first symbol that has
entry in global part of the .got. So, the symbol with dynamic symbol index of
DT_MIPS_GOTSYM will be placed in the first entry in the global part of the .got.
The symbol with dynamic symbol index of DT_MIPS_GOTSYM+1 will be placed in the
second entry in the global part of the .got and so on.

For the previous example, lets suppose that DT_MIPS_GOTSYM is 6. Since the
dynamic symbol index of printf is 7, printf will be placed in the global part of
the .got (in the second entry of the global part of the got), and call to printf
will go through .got and lazy binding stub, and will be resolved by dynamic
linker.

>From the previous explanation, it should be clear why calling functions through
.got on Mips doesn't need any relocations. Dynamic linker knows which .got entry
corresponds to which symbol, based on matching between .got and dynamic symbol
table. For the plt, on the other hand, there is no matching between the .got.plt
entry and the dynamic symbol table - function addresses in .got.plt can come in
arbitrary order. This is why every .got.plt entry needs R_MIPS_JUMP_SLOT
relocation - so that dynamic linker knows which symbol corresponds to this entry.
(Note that on Mips, pointers to functions which are accessed though plt are
placed in separate .got.plt section, not in .got like on Intel for example.)



To summarize, the method to determine whether the call to function will go
through .got and lazy binding stub is:
- find the value of dynamic symbol index of the function with the command 
  "readelf --dyn-syms"
- find the value of dynamic tag MIPS_GOTSYM with the command "readelf -d"
- if (dyn_sym_index >= MIPS_GOTSYM) then the function has entry in the global
  part of the .got, and the call will go through lazy binding stub and be
  resolved by dynamic linker.

For the case that function is accessed through plt, the existing method that
searches for relocations should also be tried, with the exception that on Mips
the relocation to search for is R_MIPS_JUMP_SLOT.


Regards,
Dejan Latinović