Gnu Toolchain

From Devpit
(Redirected from Gnu Toolchain/)
Jump to: navigation, search

Building self contained GNU toolchains

NOTE: This page is being worked on.



* Built to provide binutils for gcc, current uses the system loader /lib/


* Must have hacked dynamic-linker setting to point to the new loader so that the next binutils build will have the correct loader path.


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

glibc64 binutils gcc glibc32 glibc64


* 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. provided by glibc) is invoked when an application is executed, e.g.


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/ is found before /lib/ on Power5 hardware.

At this point 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/


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/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /work/usr/src/build-23/sunrpc/xbootparam_prot.T

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/
0x0ffa3660  0x0ffd1670  Yes         /opt/at05/lib/
0x0fe2e3c0  0x0ff4c0b0  Yes         /opt/at05/lib/
0x0fd52ee0  0x0fda4490  Yes         /opt/at05/lib/


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/ but finds the system toolchain instead? What is going on?

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

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

Q. I've built a toolchain into /opt/biarch/<some_location>/ 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/<some_location>/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'.


Please see the compatibility matrix wiki page.