Related articles |
---|
Mysterious triple test failures nmh@t3x.org (Nils M Holm) (2014-05-03) |
Re: Mysterious triple test failures kaz@kylheku.com (Kaz Kylheku) (2014-05-03) |
Tripe test failure update nmh@t3x.org (Nils M Holm) (2014-05-04) |
Re: Triple test failure update cdodd@acm.org (Chris Dodd) (2014-05-23) |
Re: Triple test failure update nmh@t3x.org (Nils M Holm) (2014-05-23) |
Re: Triple test failure update alexfrunews@gmail.com (2014-05-23) |
From: | "Nils M Holm" <nmh@t3x.org> |
Newsgroups: | comp.compilers |
Date: | Fri, 23 May 2014 09:09:11 +0200 |
Organization: | Compilers Central |
References: | 14-05-003 14-05-004 14-05-008 14-05-027 |
Keywords: | storage, debug |
Posted-Date: | 23 May 2014 12:45:44 EDT |
Chris Dodd <cdodd@acm.org> wrote:
> So the difference is in the assembler or the linker.
>
> Have you tried turning off ASLR (address space randomization)? You
> can do this on linux with
>
> # echo 0 > /proc/sys/kernel/randomize_va_space
>
> If there is anything in the assembler or linker that depends on
> addresses allocated in memory (such as hash tables?) then ASLR will
> move things around, which may result in things being processed in a
> different order and laid out differently.
Ah, this is interesting! I had previously thought about ASLR, but
then thought that it cannot affect executables as long as they merely
sit on the hard disk. Your comment sheds new light on this aspect.
Unfortunately, I have never been able to reproduce this behavior
myself (only heard about it from testers) and currently it does not
seem to be reproducible anywhere. This happened after I changed the
Makefile from
scc *.c
to
scc $(SRC)
so it looks like John and a few others here in c.c. where right. It
was most probably the order of objects passed to the linker. However,
should the problem re-appear, I will definitely try what you suggested!
Thanks!
Nils
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Return to the
comp.compilers page.
Search the
comp.compilers archives again.