32-bit MinGW build with JIT

[Eli Zaretskii <eliz@gnu.org>]

I tried to build the JIT branch with 32-bit MinGW tools.  Since Tom
said wide ints are not yet supported, I didn't configure with that
option.

The build failed half way through bootstrap.  Specifically,
bootstrap-emacs crashes the first time it attempts to JIT-compile a
byte-compiled function, and then invoke the resulting JIT.

The crash is in this snippet from eval.c:

#ifdef HAVE_LIBJIT
         if (initialized)
           {
             struct Lisp_Vector *vec = XVECTOR (fun);

             if (vec->contents[COMPILED_JIT_CODE] == NULL)
               emacs_jit_compile (fun);

             if (vec->contents[COMPILED_JIT_CODE] != NULL)
               return funcall_subr (fun,
                                    (struct subr_function *) vec->contents[COMPILED_JIT_CODE],
                                    nargs, arg_vector);
           }
#endif /* HAVE_LIBJIT */

funcall_subr calls the JIT function, which attempts to call Ffuncall,
and the latter segfaults because its arguments are not valid Lisp
objects.

I'm not yet sure what causes this, but since I presume that the branch
was successfully built on a 64-bit host, I suspect some snafu with
pointers that are narrower than 64-bit integers.  I couldn't yet spot
any code that would be suspect, although some portions of the code
work differently on 64-bit and 32-bit hosts, for example:

  if (sizeof (ptrdiff_t) == 8)
    ptrdiff_t_type = jit_type_ulong;
  else
    {
      eassert (sizeof (ptrdiff_t) == 4);
      ptrdiff_t_type = jit_type_uint;
    }

(This is btw wrong, I think, in a 32-bit build --with-wide-int.)

Also, I'm not sure why we are making a "long constant" (i.e., a 64-bit
data type) here:

         mandatory_val
           = jit_value_create_long_constant (func, ptrdiff_t_type, mandatory);

Why shouldn't this be of the same type as ptrdiff_t_type?

Anyway, what I wanted to tell is that as of now, it is very hard to
debug these problems.  All the libjit types are "incomplete" as far as
GDB is concerned, there are no facilities to display libjit types and
values in human-readable form, C-level backtraces show ?? when a JIT
compiled function is called, etc.  I didn't yet succeed in
establishing whether the invalid Lisp arguments for Ffuncall are
already invalid when we compile the function, or get corrupted as part
of compilation.

I think we need to upgrade our debugging facilities, including adding
commands to .gdbinit, as part of working on this branch.

Tom, if you didn't try to build on a 32-bit host, could you please try
that, so I could decide if what I report is specific to a 32-bit build
or to MS-Windows?

Thanks.