mirror of
https://github.com/bminor/binutils-gdb.git
synced 2025-12-28 10:00:51 +00:00
40726f16a8
Parsing symbol or file/section names in ld linker scripts is a little
complicated. Inside SECTIONS, a name might be the start of an
expression or an output section. Is ".foo=x-y" a fancy section name
or is it the expression ".foo = x - y"? It isn't possible for a
single lookahead parser to decide, so the answer in this case is
that it's a section name. This is the reason why everyone writes
linker script assignment expressions with lots of white-space.
However, there are many places where the parser knows for sure that an
expression is expected. Those could be written without whitespace
given the first change to ldlex.l below. Unfortunately, that runs
into a lookahead problem. Optional expressions at the end of an
output section statement require the parser to look ahead one token in
expression context. For this example from standard scripts
.interp : { *(.interp) }
.note.gnu.build-id : { *(.note.gnu.build-id) }
at the end of the .interp closing brace, the parser is looking for
a possible memspec, phdr, fill or even an optional comma. The next
token is a NAME, but in expression context that NAME now doesn't
include '-' as a valid char. So the lookahead NAME is
".note.gnu.build" with an unexpected "-id" syntax error before the
colon. The rest of the patch involving ldlex_backup arranges to
discard that NAME token so that it will be rescanned in the proper
script context.
* ldgram.y (section): Call ldlex_backup. Remove empty action.
* ldlex.h (ldlex_backup): Declare.
* ldlex.l (<EXPRESSION>NAME): Don't use NOCFILENAMECHAR set of
chars, use SYMBOLNAMECHAR.
(ldlex_backup): New function.
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.