Re: VIRT_ADDR_VARIES

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

On 11/09/11 20:05, Stephen J. Turnbull wrote:
> We don't live in a traditional world anymore.  We have SELinux,...

Yes, of course, but the question isn't whether we
have non-traditional layouts -- of course we have them.
The question is: on what type of platform is VIRT_ADDR_VARIES
correctly unset (i.e., the traditional model is good enough
for Emacs), but this approach breaks down when running under
valgrind?

Let me try to state the issue more concretely.
I don't observe the problem on my host (Fedora 15 x86-64),
even though it has address space randomization.
If I run these two shell commands:

         ./temacs --batch --eval '(progn (insert-file "/proc/self/maps") (message "%s\n" (buffer-string)))'

valgrind ./temacs --batch --eval '(progn (insert-file "/proc/self/maps") (message "%s\n" (buffer-string)))'

I get quite different outputs, but the text, data, and bss
segments are laid out identically in both cases, and they're
always laid out before the heap.  That is, the output looks
like this both times:

  00400000-00634000 r-xp 00000000 09:02 106972830                          .../src/temacs
  00834000-00adc000 rw-p 00234000 09:02 106972830                          .../src/temacs
  00adc000-00b63000 rw-p 00000000 00:00 0
  [...everything else...]

Here the first line is text, the second data, the third bss.
Because the heap is after the data in both cases,
Emacs works in both cases, and there's no need to define
VIRT_ADDR_VARIES, regardless of whether valgrind is used.

Can someone run those two commands on a GNU/Linux host where valgrind
breaks things, and use the output to explain why the breakage
occurs?  That might help explain the issue better.