This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
What is the purpose of this patch ?
- To: Nick Clifton <nickc at cygnus dot com>
- Subject: What is the purpose of this patch ?
- From: Alex Samuel <samuel at codesourcery dot com>
- Date: Thu, 13 Jul 2000 15:11:59 -0700 (PDT)
- CC: gcc at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <200007132133.OAA14561@elmo.cygnus.com>
Nick Clifton <nickc@cygnus.com> writes:
Nick> Please could you tell me the purpose of the following patch ?
2000-06-21 Alex Samuel <samuel@codesourcery.com>
...
The new C++ ABI mandates a demangler entry point, called
__cxa_demangle, in the language support runtime. Most commonly, it is
used to demangle the (mangled) type name that is stored in a typeinfo
struct. That patch added the entry point.
Nick> I ask because it has broken building cross compilers (well
Nick> the arm-elf cross compiler at least, and I assume other
Nick> targets as well). The reason is that the files cp-demangle.c
Nick> and dyn-string,c include <stdio.h> (amoungst others) and this
Nick> header is not available during a build of a cross compiler.
The original code #included stdio.h conditionally, omitting it when
building the demangler for inclusion in libgcc (it's needed only if
you enable tracing output, or to build a stripped down standalone
demangler independent of c++filt).
Apparently, this broke things on some platforms which get the
definition of NULL from stdio.h, so Phillippe De Muyter made the
#include unconditional; see
http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00223.html
Nick> I have come up with a patch to fix the problem, that edits
Nick> these files and adds #ifndef inhibit_libc...#endif around the
Nick> offending #includes, but I feel that this is the wrong way to
Nick> solve the problem.
There's no need to invent a new condition flag for this; the original
code used
#if defined(CP_DEMANGLE_DEBUG) || defined(STANDALONE_DEMANGLER)
#include <stdio.h>
#endif
which should be sufficient. However, that leaves NULL undefined on
some systems. I don't know enough about header files on the various
and sundry systems out there to know what the right answer is.
My feeling is that stdio.h shouldn't get included if the code does no
I/O, so I hope someone on the gcc list can suggest the right solution.
Regards
Alex Samuel
CodeSourcery LLC