bug#36649: 27.0.50; pure space and pdumper

[Eli Zaretskii]

> Date: Mon, 17 May 2021 17:23:50 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eggert@cs.ucla.edu, rpluim@gmail.com, stefan@marxist.se,
>  schwab@linux-m68k.org, monnier@iro.umontreal.ca, pipcet@gmail.com,
>  36649@debbugs.gnu.org, akrl@sdf.org
> 
> If no one else is willing to debug the unexec problems, I will do it
> myself, at my own pace.

Now done.  At least the unoptimized build with unexec runs cleanly to
completion on GNU/Linux.  Turns out we broke this about 1.5 year ago,
when an unrelated change inadvertently disabled the use of
HYBRID_MALLOC in this build, which is a must for unexec to work on
this platform.

There's one aspect of the changeset I pushed that I'm uneasy about.
It is this part in configure.ac:

  diff --git a/configure.ac b/configure.ac
  index 3df4359..d35ac6d 100644
  --- a/configure.ac
  +++ b/configure.ac
  @@ -2306,6 +2309,9 @@ AC_DEFUN
     GNU_MALLOC_reason=" (only before dumping)"
     GMALLOC_OBJ=gmalloc.o
     VMLIMIT_OBJ=
  +  # FIXME: This is to prevent Gnulib from redirecting 'free' to its
  +  # replacement, instead of 'hybrid_free' in gmalloc.c.
  +  gl_cv_func_free_preserves_errno=yes
   else
     test "$doug_lea_malloc" != "yes" && GMALLOC_OBJ=gmalloc.o
     VMLIMIT_OBJ=vm-limit.o

The problem here is that Gnulib wants to redirect 'free' to its
replacement 'rpl_free', and that breaks our own redirection, in
conf_post.h, to 'hybrid_free' (of gmalloc.c), which we _must_ use in
this configuration.  I couldn't find a clean fix, so for now the
unexec build will not use the Gnulib replacement for 'free'.

Paul, if this kludge annoys you enough (I hope it will), please
suggest a cleaner way out of this conundrum.