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 libld-l4.so:
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 libld-l4.so 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:
_ITM_deregisterTMCloneTable _ITM_registerTMCloneTable __deregister_frame_info
(It is worth noting at this point that the "_ITM" symbols are also undefined in the CI20's libld-l4.so, 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 libgcc_s.so. However, amongst the libgcc binaries in the L4Re build directory, only the following provides the object:
pkg/l4re-core/libgcc/lib/OBJ-mips_32-l4f/libgcc-l4.so
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.
Paul