Gnu Toolchain

= Building self contained GNU toolchains =

NOTE: This page is being worked on.

Stages:

binutils * Built to provide binutils for gcc, current uses the system loader /lib/ld.so gcc * Must have hacked dynamic-linker setting to point to the new loader so that the next binutils build will have the correct loader path.

glibc32 * Built with the new gcc and provide a base level of libraries glibc64 binutils gcc glibc32 glibc64

binutils * Built to pick up the correct loader path.

= Linker vs. Loader = The static linker (i.e. ld provided by binutils) is invoked when applications are compiled and linked, e.g. gcc test.c -o test -lm In this example libm is indicated in the link. Linkage provides three things, Library name, version, and symbols.

The dynamic linker/loader (i.e. ld.so provided by glibc) is invoked when an application is executed, e.g. ./test At this stage the AT_PLATFORM is checked for the architecture specific cpu and the loader looks for a library which matches, e.g. /lib/power5/libm.so is found before /lib/libm.so on Power5 hardware. At this point ld.so loads the necessary libraries and finishes dynamic relocations any remaining symbols that couldn't be relocated at compile time.

= Debugging applications which don't use the standard loader =

Invoke gdb against the loader that you've built and invoke gdb64 -x /work/usr/src/build-23/rpcgen.gdb -cd=/work/usr/src/libc23/sunrpc /work/usr/src/build-23/elf/ld64.so.1

rpcgen.gdb set environment CPP gcc64t -E -x c-header b *0x080158f4 b *0x08015ac8 b *0x080059e8 run --library-path /work/usr/src/build-23:/work/usr/src/build-23/math:/work/usr/src/build-23/elf:/work/usr/src/build-23/dlfcn: /work/usr/src/build-23/nss:/work/usr/src/build-23/nis:/work/usr/src/build-23/rt:/work/usr/src/build-23/resolv: /work/usr/src/build-23/crypt:/work/usr/src/build-23/linuxthreads /work/usr/src/build-23/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /work/usr/src/build-23/sunrpc/xbootparam_prot.T --direct

Note: the --direct flag is required because the GLIBC make check test-skeleton takes the --direct flag as an indication to not fork a process for the particular test but to rather run it inline.

= Getting the loaded library offsets in GDB =

Use the gdb command 'info shared' to determine at which offsets the dynamically linked libraries are loaded.

Breakpoint 1, 0x100005a4 in main (gdb) info shared From       To          Syms Read   Shared Object Library 0xf7fe1280 0xf7ffa830  Yes         /opt/at05/lib/ld.so.1 0x0ffa3660 0x0ffd1670  Yes         /opt/at05/lib/libdfp.so 0x0fe2e3c0  0x0ff4c0b0  Yes         /opt/at05/lib/libc.so.6 0x0fd52ee0 0x0fda4490  Yes         /opt/at05/lib/libm.so.6 (gdb)

= FAQ =

Q. My self contained toolchain's `as' or `ld' doesn't find the right libc. Notice how /opt/biarch/tc/bin/as doesn't find /opt/biarch/tc/lib/tls/libc.so.6 but finds the system toolchain instead? What is going on?

LD_DEBUG=libs /opt/biarch/tc/bin/as 622: find library=libc.so.6 [0]; searching 622:  search cache=/etc/ld.so.cache 622:   trying file=/lib/tls/libc.so.6

A. You need to make sure that you've modified /opt/biarch/tc/etc/ld.so.conf and rerun /opt/biarch/tc/sbin/ldconfig.

Q. I've built a toolchain into /opt/biarch// but when I try to run an application I get the following error. Why?

usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/../../../../powerpc-suse-linux/bin/ld: /home/ryanarn/packages/build/glibc32_dfp/csu/crti.o: unknown relocation type 250 for symbol _GLOBAL_OFFSET_TABLE_

A. One of two things has happened.
 * Your environment has lost the PATH to your speciality toolchain and you'll need to re-export your path.

export PATH="/opt/biarch//bin:$PATH"


 * You're missing a step in your toolchain build process. Was 'ld' built with a gcc which specified the /opt/biarch toolchain location?

Note: Relocation type 250 for symbol _GLOBAL_OFFSET_TABLE_ is a PIC relocation type for 'secure-plt'.

= Compatibility = Please see the compatibility matrix wiki page.