This is a backport of 6bead319.

That procedure doesn't work correctly if hart 0 comes out of reset while
hart 1 is still in reset.

Fix --disable-fp-emulation.

Fix macros for emulating atomic operations (--disable-atomics).

Add missing #include for config.h

This has the side effect of testing the IPI mechanism.  Still not sure
this is the best approach to booting, but it works...

Run it yourself if you modify configure.ac, and commit the configure script.

This works around a stack overflow.

It breaks programs that rely on ELF program headers.

We were already trying to handle this case, but we got it wrong.

Previously, a bug caused only some page tables to be zeroed on RV64.

Of course, this should probably be read from a CSR or platform register.

mremap was badly broken, and maybe it's not worth the time to fix it.
glibc still seems to work ok, because the malloc implementation handles
mremap failure gracefully (though at a performance cost).

Change the behavior of the DESTDIR make variable

DESTDIR is a common make idiom.  As per the GNU coding standards

  https://www.gnu.org/prep/standards/html_node/DESTDIR.html

  "DESTDIR is a variable prepended to each installed target file, like
  this:

  $(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo
  $(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a

  The DESTDIR variable is specified by the user on the make command
  line as an absolute file name. For example:

  make DESTDIR=/tmp/stage install

  DESTDIR should be supported only in the install* and uninstall*
  targets, as those are the only targets where it is useful.

  If your installation step would normally install /usr/local/bin/foo
  and /usr/local/lib/libfoo.a, then an installation invoked as in the
  example above would install /tmp/stage/usr/local/bin/foo and
  /tmp/stage/usr/local/lib/libfoo.a instead."

The current Makefile.in uses DESTDIR, but has a slightly non-standard
behavior: the target install location doesn't include "$prefix".  This
breaks package managers, because stuff ends up getting installed to
the wrong location.

Unfortunately the only way I can think of to fix this involves
silently changing the behavior of DESTDIR.  Hopefully nobody is using
it...?

[port of 8a2088b59162fe16c16d26ddc1cfcaaaa8c4156f in riscv-fesvr]