forked from Imagelibrary/binutils-gdb
5de9eada3b
This machinery has been broken for as long as Solaris has existed. Forwards are meant to encode "struct foo;", "enum foo;" or "union foo;". Obviously these all exist in distinct namespaces, so forwards store the type kind they forward to in their ctt_type member (which makes conceptual sense if you squint at it). The addition machinery uses this to promote forwards to the appropriate type as needed. Unfortunately ctf_add_type does not: it checks the global namespace (which is always wrong), and so fails with a spurious conflict if you have, say, a typedef and then a forward comes along with the same name, even if it's a forward to something like a struct. (This was observed with <libio.h>, which has "struct _IO_FILE;" and also "typedef struct _IO_FILE _IO_FILE"). We should look at the recorded type kind and look in the appropriate namespace. We should also, when creating the forward in the new container, use that type kind, rather than just defaulting to CTF_K_STRUCT and hoping that what eventually comes along is a struct. This bug is as old as the first implementation of ctf_add_type in Solaris. But we also want a new feature for the linker, closely-related and touching the same code so we add it here: not only do we want a forward followed by a struct/union/enum to promote the forward, but we want want a struct/union/enum followed by a forward to act as a NOP and return the existing type, because when we're adding many files in succession to a target link, there will often be already-promoted forwards (in the shape of a struct/union/enum) that want to unify with duplicate forwards coming from other object files. v5: fix tabdamage. libctf/ * ctf-create.c (ctf_add_type): Look up and use the forwarded-to type kind. Allow forwards to unify with pre-existing structs/ unions/enums.
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.