bug#23529: Request for fixing randomize_va_space build issues

[Paul Eggert <eggert@cs.ucla.edu>]

On 09/09/2016 11:45 AM, Eli Zaretskii wrote:
> All of those data structures are memory allocated for Lisp objects and
> their supporting structures, with known structures, so we know exactly
> which pointers need fixing.

Of course. But it's not trivial to fix them. It can be done, but it will 
take code that will be hard to maintain portably.

> gmalloc is already implemented

Yes, and its problems are prompting this discussion. gmalloc was a fine 
design for the 1980s but is not now.

> If there are libc's out there that allow the application to define its
> own sbrk, then we could use that (we do on Windows).

The sbrk model is becoming less and less plausible.

> If not, gmalloc
> will be good enough for the temacs run; emacs will of course use the
> normal libc allocators.

This would give up on redumping, no? Plus, it assumes sbrk, which is 
backward-looking. POSIX has withdrawn support for sbrk and there is 
movement to deprecate it in C libraries due to security/robustness 
concerns. This is something we should encourage, not run away from.

> What is a "block" in this context? Surely, a data structure with
> linked pointers cannot be distributed between different "blocks",
> since a linker will not know how to fixup each address, because it
> doesn't understand the data structure.

It can be distributed between different "blocks", because we can tell 
the compiler and linker the data structure. Here's a quick example with 
two small "blocks" dX and dY (the actual code would differ, this is just 
a proof of concept):

   /* Simplified version of lisp.h.  */
   #include <stdint.h>
   typedef intptr_t Lisp_Object;
   enum { Lisp_Int0 = 2, Lisp_Cons = 3 /* ... */};
   #define make_number(n) (((n) << 2) + Lisp_Int0)
   #define TAG_PTR(tag, ptr) ((intptr_t) (ptr) + (tag))
   #define Qnil ((Lisp_Object) 0)
   struct Lisp_Cons { Lisp_Object car, cdr; };

   /* Define a statically-allocated pair x that is equal to (10).  */
   struct Lisp_Cons dX = { make_number (10), Qnil };
   #define x TAG_PTR (Lisp_Cons, &dX)

   /* Use x to build a statically-allocated list y that is equal to (5 
10).  */
   struct Lisp_Cons dY = { make_number (5), x };
   #define y TAG_PTR (Lisp_Cons, &dY)


> We won't be able to use them as just compilers and linkers. We will
> be using them for a job that is quite a bit more complex and
> different.

No, this sort of thing is something that compilers and linkers do all 
the time.