Fix calls to malloc, realloc in prefix.c

[Kaveh R. Ghazi]

 > From: Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
 > 
 > > The results fall into these categories:
 > > 
 > > 1.  comments containing the word "malloc()".
 > > 2.  local implementations of xmalloc which need malloc, e.g. gen*.c
 > > 3.  bison generated files which call malloc, e.g. c-parse.c
 > > 4.  files which don't include system.h and/or don't link with libiberty.a,
 > >     e.g. libgcc2.c, etc.
 > > 5.  mistaken calls to malloc which should be xmalloc, e.g. prefix.c.
 > > 6.  a few cases where we *might* really need to call malloc.
 > 
 > OK, doing that and hacking out the testsuite leaves 115 files. 3 mention it
 > only in comments, a file is probably a duplicate (for
 > texinfo/info/echo[-_]area.[ch] all 4 exist, but the '_' variants aren't
 > mentioned in the Makefile.in AFAIS).
 > 
 > After weeding out what looks like reasonable uses of malloc(3) which are
 > checked, this leaves:
 > 
 > gcc/cppalloc.c: defines xmalloc()/xrealloc()
 > 
 >   Looks like that's its purpose. Why not libiberty?

IIRC, libcpp.a was designed to be standalone, so it needed to provide
its own implementation of xmalloc, etc.  I don't know if this is still
considered useful/desirable.



 > gcc/genattr.c: defines xmalloc()/xrealloc()
 > gcc/genattrtab.c: defines xmalloc()/xrealloc()
 > gcc/gencheck.c: defines xmalloc()
 > gcc/gencodes.c: defines xmalloc()/xrealloc()
 > gcc/genconfig.c: defines xmalloc()/xrealloc()
 > gcc/genemit.c: defines xmalloc()/xrealloc()
 > gcc/genextract.c: defines xmalloc()/xrealloc()
 > gcc/genflags.c: defines xmalloc()/xrealloc()
 > gcc/gengenrtl.c: defines xmalloc()
 > gcc/genopinit.c: defines xmalloc()/xrealloc()
 > gcc/genoutput.c: defines xmalloc()/xrealloc()
 > gcc/genpeep.c: defines xmalloc()/xrealloc()
 > gcc/genrecog.c: defines xmalloc()/xrealloc()
 > 
 >    Many (all?) of these mention they should be converted to use libiberty.

Not until we build host & build copies of libiberty.

 > 
 > 
 > gcc/doschk.c: unchecked (87, 89, 90, 91, 244)
 > gcc/frame.c: unchecked (272, 771, 827?, 856?)
 > gcc/libgcc2.c: unchecked (1976, 1988, 2318)
 > gcc/prefix.c: unchecked (142, 214?)
 > gcc/f/fini.c: unchecked (368)
 > libiberty/mpw.c: unchecked (184, 655, 861)
 > libio/floatconv.c: unchecked (414)
 > gcc/fixinc/gnu-regex.c: unchecked (2906); *TALLOC* macros aren't checked AFAIKS
 > gcc/intl/dcgettext.c: ADD_BLOCK fishy (186); define alloca, assume it works (279, 286, 307, 316)
 > gcc/intl/localealias.c: #define alloca(), assume it works (228); ADD_BLOCK fishy (106)
 > 
 >    All of the above contain what looks like legitimate uses of malloc(3),
 >    but the result is not checked on the calls on the lines mentioned. Very
 >    fishy. Some #define alloca to malloc(3), and don't check what it returns
 >    either... and gnu-regex seems not to check the return values of its many
 >    *TALLOC* macros anywhere.

Of the files mentioned above, only prefix.c and f/fini.c include
system.h and link with libiberty.a.  This is a requirement for files
covered by my proposal to define malloc, etc, to #error.

We should indeed ensure all calls to malloc check the return value vs.
NULL, but to *enforce* this we'll have to approach it differently for
target files like libgcc2.c and files outside the gcc dir, like
libiberty/mpw.c.

 > 
 > > I think adding the #error to system.h would help us catch all of #5.
 > 
 > AFAIKS, your idea won't catch the worst of the above, i.e., uses in files
 > that end up in libraries. A crashing compiler sure is bad, but one that
 > creates executables that misteriously crash is worse IMVHO.

Right, we'll have to modify our approach to handle stuff in target
libs which can't link against libiberty and use xmalloc.  That doesn't
mean we can't start somewhere. :-)


 > > Cases 1 & 4 won't be affected by a define in system.h and for 2, 3 & 6
 > > we can undef malloc locally.  (An alternate solution for #2 would be
 > > to finally generate both host & build copies of libiberty and nuke the
 > > local implementations of xmalloc.)
 > 
 > AFAIU, the gen* programs run on the build machine for the compiler, so they
 > could use libiberty from day one. Or am I missing something here?

No.  The gen* cannot be linked with the libiberty we compile today.
We have to arrange for compile both host & build libiberty.a.

Care to do this?

It would involve modifying the top level Makefile.in to use
symlink-tree to copy the libiberty dir (into build-libiberty) and
compile it using (I think) $HOST_CC.  (Jeff suggested always building
two libiberty.a for Makefile simplicity even when not doing a
canadian-cross compile.)

Once that is done, we can modify gcc/Makefile.in to link gen* with
../build-libiberty/libiberty.a and nuke all the redundant xmalloc,
etc, definitions in gen*.c, et al.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions