bug#23529: Request for fixing randomize_va_space build issues

[Philippe Vaucher]

> Some background: Emacs has an 'undump' function that saves the Emacs state as 
> an
> executable: when you run the executable, you get an Emacs with the same (or
> nearly the same) state. This makes Emacs startup considerably faster. Objects 
> in
> the restored state must be in the same location as when they were saved, so 
> the
> executable cannot be subject to ASLR.

Alright, that makes sense now.

> I don't know all the ins and outs of why it is necessary for Emacs to invoke
> 'personality'. As I understand it, the build procedure should invoke the shell
> command 'setfattr -n user.pax.flags -v er temacs' immediately after building
> temacs, and I don't know why this doesn't make the 'personality' call
> unnecessary. Perhaps you can consult a seccomp expert who can tell you what's
> going on, as seccomp is not well-documented. If there is some way to disable
> ASLR without calling 'personality', that should fix your problem.

I'll try to debug the `setfattr` part to see what it does. I seems
that `setarch -R` and `personality` both "works" return-status wise
but in practice inside docker they don't change anything (and thus
don't disable ASLR). It looks like eventually the problem will be
fixed on the docker side... but maybe the debug session will yield
some emacs patch.

> Regardless, the advice in etc/PROBLEMS is clearly obsolete here, so I 
> installed
> the attached patch to try to make things clearer. We're not going to greatly
> alter the dumping procedure before Emacs 25 comes out (it's too late in the
> release process) but we should do better in the future. For now we should at
> least document the issues better.

Ah, good patch! About the dumping procedure, do you mean there *is* a
plan to alter it after Emacs 25 comes out? The building behavior on
this issue about ASLR between 24.5 and 25.0.93 seems very similar from
my experience.

>> I tried to run "./temacs --batch --load loadup bootstrap" inside GDB
>> to get more insights about why it segfaults there, but somehow gdb
>> fails to catch it. Maybe because of spawned processes?
>
> Yes, the code you highlighted does an execvp. You might try fiddling with 
> GDB's
> follow-exec-mode variable; see
> <https://sourceware.org/gdb/onlinedocs/gdb/Forks.html>.

I'll play with it. Thanks!
Philippe