binutils-gdb modified for the FreeChainXenon project
![]() It is usually possible to tell absolute and ordinary symbols apart in BFD throughout the link, by checking whether the section that owns the symbol is absolute or not. That however does not work for ordinary symbols defined in a linker script outside an output section statement. Initially such symbols are entered into to the link hash as absolute symbols, owned by the absolute section. A flag is set in the internal linker expression defining such symbols to tell the linker to convert them to section-relative ones in the final phase of the link. That flag is however not accessible to BFD linker code, including BFD target code in particular. Add a flag to the link hash then to copy the information held in the linker expression. Define a macro, `bfd_is_abs_symbol', for BFD code to use where determining whether a symbol is absolute or ordinary is required before the final link phase. This macro will correctly identify the special `__ehdr_start' symbol as ordinary throughout link, for example, even though early on it will be assigned to the absolute section. Of course this does not let BFD code identify what the symbol's ultimate section will be before the final link phase has converted this symbol (in `update_definedness'). include/ * bfdlink.h (bfd_link_hash_entry): Add `rel_from_abs' member. bfd/ * linker.c (bfd_is_abs_symbol): New macro. * bfd-in2.h: Regenerate. ld/ * ldexp.c (exp_fold_tree_1) <etree_assign, etree_provide> <etree_provided>: Copy expression's `rel_from_abs' flag to the link hash. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
ar-lib | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
COPYING3 | ||
COPYING3.LIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
lt~obsolete.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 | ||
test-driver | ||
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.