mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-19 09:14:14 +08:00
558802e4d1
Change this field to an std::vector to facilitate memory management. Since the linetable_entry array is copied into the symtab resulting from the subfile, it is possible to change it without changing how symtab stores the linetable entries (which would be a much larger change). There is a small change in buildsym_compunit::record_line to avoid accessing a now invalid linetable_entry. Before this patch, we keep a pointer to the last linetable entry, pop it from the vector, and then read last->line. It works with the manually-maintained array, but since we now use std::vector::pop_back, I am afraid that it could be flagged as an invalid access by the various static / dynamic analysis tools to access the linetable_entry object after popping it from the vector. Instead, record just the line number in an optional and use it. There are substantial changes in xcoffread.c that simplify the code, but I can't test them. I was hesitant to do this change because of that, but I decided to send it anyway. I don't think that an almost dead platform should hold back improving the code in the common parts of GDB. The changes in xcoffread.c are: - Make arrange_linetable "arrange" the linetable passed as a parameter, instead of returning possibly a new one, possibly the same one. - In the "Process main file's line numbers.", I'm not too sure what happens. We get the lintable from "main_subfile", "arrange" it, but then assign the result to the current subfile, obtained with get_current_subfile. I assume that the current subfile is also the main one, so now I just call arrange_linetable on the main subfile's line table. - Remove that weird "Useless if!!!" FIXME comment. It's been there forever, but the "if" is still there, so I guess the "if" can stay there. Change-Id: I11799006fd85189e8cf5bd3a168f8f38c2c27a80
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.