Binutils with MCST patches
fdb09caf23
The test case builds two copies of the program, one with the compile option "ldflags=-Wl,-Ttext=0x1000000" and the other with the address changed to 0x2000000. However, when linking with ld.bfd, the resulting executables crash early in ld.so on S390 and i386. Analysis of the crash: The default linker script establishes a certain order of loadable sections, and the option "-Ttext" effectively splits these into an "unaffected" lot (everything before .text) and an "affected" lot. The affected lot is placed at the given address, whereas the unaffected lot stays at its default address. The unaffected lot starts at an aligned address plus Elf header sizes, which is good if it is the first LOAD segment (like on AMD64). But if the affected lot comes first instead (like on S390 and i386), the PHDR doesn't fit there and is placed *outside* any LOAD segments. Then the PHDR is not mapped when the loader gets control, and the loader runs into a segmentation fault while trying to access it. Since we are lucky about the order of segments on AMD64, the test succeeds there, but the resulting binaries are unusually large -- 2.1M each, with lots of padding within. When replacing '-Ttext' by '-Ttext-segment', the linker moves all segments consistently, the binaries have normal sizes, and the test case succeeds on all mentioned platforms. Since old versions of the gold linker don't support '-Ttext-segment', the patch also adds logic for falling back to '-Ttext'. gdb/testsuite/ChangeLog: * gdb.base/execl-update-breakpoints.exp: Specify the link address with '-Ttext-segment' instead of '-Ttext'. Fall back to '-Ttext' if the linker doesn't understand this. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING3 | ||
COPYING3.LIB | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
lt~obsolete.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
ylwrap |
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.