bug#23529: Request for fixing randomize_va_space build issues

[Paul Eggert]

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.