C++ PATCH: demangler bugs

[Jeffrey A Law]

  In message < 20000806142459H.mitchell@codesourcery.com >you write:
  > 
  > Alex --
  > 
  >   Are you sure that the config.h that is being included in these files
  > is supposed to be the config.h/tconfig.h file, as opposed to the one
  > generated by libiberty's configure script?  I bet it's supposed to be
  > the latter, and if we're currently including gcc/config.h instead when
  > building libgcc2 that's probably a bug.
libgcc2.c includes tconfig.h & tsystem.h not config.h.  Though it's possible
one of its other include files sucks in config.h, which I agree would be bad.


  >   I think it would be better to move this stuff to libstdc++, where we
  > avoid the header file issues.  Even though this stuff is specified by
  > the IA64 C++ ABI, it's not really run-time support in the same sense
  > as typeinfo or `operator new'.  For libstdc++-v2, I think that's as
  > simple as adding dyn-string.o and cp-demangle.o to the NEEDED list in
  > libiberty/Makefile.in.  For libstdc++-v3, I don't know how this works.
Yea, that would simplify a number of issues, both for native and cross
builds and should be relatively simple since libstdc++ has mechanisms to
pick up .o files from libiberty.


  >   I think we should simply remove these files from libgcc, for now.
  > We should figure out how to get them into libstdc++-v3, since that's
  > where they need to end up, eventually.  I know this is my fault, since
  > I originally believed they should be part of libgcc, and I apologize
  > for wasting your time.  (Fortunately, the work that you did to rename
  > functions out of the user namespace in these files is still useful;
  > we'll need these wherever the files end up.)
Seems like a reasonable thing to me.


  >   (Also, there's a mistake in the licensing notice at the top of these
  > files.  It says that both cp-demangle.c and dyn-string.c are GPL, but
  > that's not appropriate for use in either libgcc or libstdc++.  It also
  > says that dyn-string.c is GPL'd, which is also inappropriate for use
  > in libgcc.  In my opinion, these files should have the additional
  > paragraph, found in libgcc2.c:
  > 
  >   In addition to the permissions in the GNU General Public License, the
  >   Free Software Foundation gives you unlimited permission to link the
  >   compiled version of this file into combinations with other programs,
  >   and to distribute those combinations without any restriction coming
  >   from the use of this file.  (The General Public License restrictions
  >   do apply in other respects; for example, they cover modification of
  >   the file, and distribution when not linked into a combine
  >   executable.)
  > 
  > I will raise this issue with the SC.)
Agreed, we should put the exception clause on them.
jeff