GNU bug report logs - #23529
Request for fixing randomize_va_space build issues

Previous Next

Full log

Message #140 received at 23529 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, philippe.vaucher <at> gmail.com, 23529 <at> debbugs.gnu.org
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
Date: Fri, 9 Sep 2016 12:59:16 -0700

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.