Building programs with MODE=shared in L4Re

Paul Boddie paul at
Wed Jun 27 00:43:33 CEST 2018

On Sunday 17. June 2018 01.07.44 Paul Boddie wrote:
> With these details, and using objdump to dump all the programs and
> libraries, I discovered that it comes from the _ftext section of
>     2f5c:       8f998250        lw      t9,-32176(gp)
>     2f60:       24a55fa8        addiu   a1,a1,24488
>     2f64:       0320f809        jalr    t9
>     2f68:       24844ee4        addiu   a0,a0,20196
>     2f6c:       8fbc0010        lw      gp,16(sp)
> So, what appears to be happening is that the "jalr t9" instruction is using
> a value for t9 that is 0x800000, which causes a jump to the object header
> and the subsequent failure.

Some more investigation (and off-list encouragement) eventually led me to 
realise what might be happening here. The table entry providing the value for 
t9 happens to be a "global" entry in the global offset table. Looking at the 
output from "readelf -a" for yields the following:

 Global entries:
   Address     Access  Initial Sym.Val. Type    Ndx Name
  00025f80 -32176(gp) 00000000 00000000 FUNC    UND __register_frame_info

Here, we see the offending entry and what the program apparently expects to 
find. Other entries that are apparently undefined are the following:


(It is worth noting at this point that the "_ITM" symbols are also undefined 
in the CI20's, whereas the other symbols do not appear at all.)

What I can see is that various libgcc binaries produced for my toolchain 
provide __register_frame_info, notably libgcc_eh.a and However, 
amongst the libgcc binaries in the L4Re build directory, only the following 
provides the object:


It isn't clear to me what relation this L4Re-built object has to the other 
libraries, however. The build system logic in the mk directory doesn't refer 
to such libraries in an obvious way. Maybe all I am missing is some linking 
option, but I cannot be certain of this.


More information about the l4-hackers mailing list