[Bug boehm-gc/52179] New: boehm-gc incompatible with aslr on darwin11

[Bug boehm-gc/52179] New: boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

             Bug #: 52179
           Summary: boehm-gc incompatible with aslr on darwin11
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: boehm-gc
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: howarth@nitro.med.uc.edu


Currently we see the failures...

FAIL: boehm-gc.c/gctest.c -O2 execution test
FAIL: boehm-gc.c/leak_test.c -O2 execution test
FAIL: boehm-gc.c/thread_leak_test.c -O2 execution test
FAIL: boehm-gc.lib/staticrootstest.c -O2 execution test

at -m32/-m64 on x86_64-apple-darwin11. Interestingly, if
boehm-gc/testsuite/lib/boehm-gc.exp is adjusted pass -Wl,-pie to these tests,
the failures are not seen under aslr on x86_64-apple-darwin10. This is the same
behavior seen for PR52042 which suggests that the issue and fix may be similar.
Perhaps the same approach used in could be applied to boehm-gc/dyn_load.c.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #1 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-08 23:55:26 UTC ---
FYI, a description of the differences between aslr in Snow Leopard and Lion can
be found at...

http://www.0xcafebabe.it/2011/10/15/on-macos-10-7-dyld-randomization/

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #2 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-09 00:34:19 UTC ---
Rebuilding x86_64-apple-darwin11.3.0/boehm-gc with  -g -O0 -DDARWIN_DEBUG and
the failing gctest at -m64 with the same allows the following backtrace to be
obtained with aslr active under Lion...


# gdb ./gctest
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov  3 21:59:02 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries .... done

(gdb) set disable-aslr off
(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/boehm-gc/testsuite/.libs/gctest 
Reading symbols for shared libraries + done
Reading symbols for shared libraries ++++........................ done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00007fff690f63d8
GC_mark_from (mark_stack_top=0x10953f000, mark_stack=0x10953f000,
mark_stack_limit=0x10954f000) at ../../../gcc-4.7-20120207/boehm-gc/mark.c:759
759          deferred = *limit;
(gdb) bt
#0  GC_mark_from (mark_stack_top=0x10953f000, mark_stack=0x10953f000,
mark_stack_limit=0x10954f000) at ../../../gcc-4.7-20120207/boehm-gc/mark.c:759
#1  0x0000000109498947 in GC_mark_some (cold_gc_frame=0x7fff6907164c "\001") at
../../../gcc-4.7-20120207/boehm-gc/mark.c:361
#2  0x00000001094906ae in GC_stopped_mark (stop_func=0x10948fb88
<GC_never_stop_func>) at ../../../gcc-4.7-20120207/boehm-gc/alloc.c:531
#3  0x000000010949026a in GC_try_to_collect_inner (stop_func=0x10948fb88
<GC_never_stop_func>) at ../../../gcc-4.7-20120207/boehm-gc/alloc.c:378
#4  0x000000010949c222 in GC_init_inner () at
../../../gcc-4.7-20120207/boehm-gc/misc.c:789
#5  0x000000010949bdbd in GC_init () at
../../../gcc-4.7-20120207/boehm-gc/misc.c:493
#6  0x00000001094758ec in main () at
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120207/boehm-gc/testsuite/boehm-gc.c/gctest.c:1803
(gdb)

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #3 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-09 00:40:19 UTC ---
A backtrace for the failing leak_test at -m64 looks identical...

# gdb ./leak_testGNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov  3
21:59:02 UTC 2011)Copyright 2004 Free Software Foundation, Inc.GDB is free
software, covered by the GNU General Public License, and you arewelcome to
change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries .... done

(gdb) set disable-aslr off
(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/boehm-gc/testsuite/.libs/leak_test 
Reading symbols for shared libraries + done
Reading symbols for shared libraries ++++........................ done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00007fff629012c8
GC_mark_from (mark_stack_top=0x102d33000, mark_stack=0x102d33000,
mark_stack_limit=0x102d43000) at ../../../gcc-4.7-20120207/boehm-gc/mark.c:759
759          deferred = *limit;
(gdb) bt
#0  GC_mark_from (mark_stack_top=0x102d33000, mark_stack=0x102d33000,
mark_stack_limit=0x102d43000) at ../../../gcc-4.7-20120207/boehm-gc/mark.c:759
#1  0x0000000102c8b947 in GC_mark_some (cold_gc_frame=0x7fff6287c53c "\001") at
../../../gcc-4.7-20120207/boehm-gc/mark.c:361
#2  0x0000000102c836ae in GC_stopped_mark (stop_func=0x102c82b88
<GC_never_stop_func>) at ../../../gcc-4.7-20120207/boehm-gc/alloc.c:531
#3  0x0000000102c8326a in GC_try_to_collect_inner (stop_func=0x102c82b88
<GC_never_stop_func>) at ../../../gcc-4.7-20120207/boehm-gc/alloc.c:378
#4  0x0000000102c8f222 in GC_init_inner () at
../../../gcc-4.7-20120207/boehm-gc/misc.c:789
#5  0x0000000102c89dda in GC_generic_malloc_inner (lb=43, k=1) at
../../../gcc-4.7-20120207/boehm-gc/malloc.c:123
#6  0x0000000102c89f74 in GC_generic_malloc (lb=43, k=1) at
../../../gcc-4.7-20120207/boehm-gc/malloc.c:192
#7  0x0000000102c8a2a1 in GC_malloc (lb=43) at
../../../gcc-4.7-20120207/boehm-gc/malloc.c:297
#8  0x0000000102c854e4 in GC_debug_malloc (lb=4, s=0x102c7df50
"/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120207/boehm-gc/testsuite/boehm-gc.c/leak_test.c",
i=9) at ../../../gcc-4.7-20120207/boehm-gc/dbg_mlc.c:491
#9  0x0000000102c7de6f in main () at
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120207/boehm-gc/testsuite/boehm-gc.c/leak_test.c:9
(gdb)

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #4 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-09 00:46:21 UTC ---
Backtrace for thread_leak_test at -m64....


# gdb ./thread_leak_testGNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu
Nov  3 21:59:02 UTC 2011)Copyright 2004 Free Software Foundation, Inc.GDB is
free software, covered by the GNU General Public License, and you arewelcome to
change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries .... done

(gdb) set disable-aslr off
(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/boehm-gc/testsuite/.libs/thread_leak_test 
Reading symbols for shared libraries + done
Reading symbols for shared libraries ++++........................ done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00007fff650f1368
GC_mark_from (mark_stack_top=0x105522000, mark_stack=0x105522000,
mark_stack_limit=0x105532000) at ../../../gcc-4.7-20120207/boehm-gc/mark.c:759
759          deferred = *limit;
(gdb) bt
#0  GC_mark_from (mark_stack_top=0x105522000, mark_stack=0x105522000,
mark_stack_limit=0x105532000) at ../../../gcc-4.7-20120207/boehm-gc/mark.c:759
#1  0x000000010547c947 in GC_mark_some (cold_gc_frame=0x7fff6506c5dc "\001") at
../../../gcc-4.7-20120207/boehm-gc/mark.c:361
#2  0x00000001054746ae in GC_stopped_mark (stop_func=0x105473b88
<GC_never_stop_func>) at ../../../gcc-4.7-20120207/boehm-gc/alloc.c:531
#3  0x000000010547426a in GC_try_to_collect_inner (stop_func=0x105473b88
<GC_never_stop_func>) at ../../../gcc-4.7-20120207/boehm-gc/alloc.c:378
#4  0x0000000105480222 in GC_init_inner () at
../../../gcc-4.7-20120207/boehm-gc/misc.c:789
#5  0x000000010547adda in GC_generic_malloc_inner (lb=144, k=1) at
../../../gcc-4.7-20120207/boehm-gc/malloc.c:123
#6  0x0000000105486d39 in GC_pthread_create (new_thread=0x7fff6506c740,
attr=0x0, start_routine=0x10546dd18 <test>, arg=0x0) at
../../../gcc-4.7-20120207/boehm-gc/pthread_support.c:1330
#7  0x000000010546ddd6 in main () at
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120207/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:28
(gdb)

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-09 00:56:13 UTC ---
Backtrace for staticrootstest at -m64...

# gdb ./staticrootstestGNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu
Nov  3 21:59:02 UTC 2011)Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries ..... done

(gdb) set disable-aslr off
(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/boehm-gc/testsuite/.libs/staticrootstest 
Reading symbols for shared libraries + done
Reading symbols for shared libraries +++++........................ done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00007fff6fbb0020
GC_mark_from (mark_stack_top=0x110037000, mark_stack=0x110037000,
mark_stack_limit=0x110047000) at ../../../gcc-4.7-20120207/boehm-gc/mark.c:759
759          deferred = *limit;
(gdb) bt
#0  GC_mark_from (mark_stack_top=0x110037000, mark_stack=0x110037000,
mark_stack_limit=0x110047000) at ../../../gcc-4.7-20120207/boehm-gc/mark.c:759
#1  0x000000010ff9081f in GC_mark_some (cold_gc_frame=0x7fff6fb2b68c "\001") at
../../../gcc-4.7-20120207/boehm-gc/mark.c:361
#2  0x000000010ff88583 in GC_stopped_mark (stop_func=0x10ff87a5d
<GC_never_stop_func>) at ../../../gcc-4.7-20120207/boehm-gc/alloc.c:531
#3  0x000000010ff8813f in GC_try_to_collect_inner (stop_func=0x10ff87a5d
<GC_never_stop_func>) at ../../../gcc-4.7-20120207/boehm-gc/alloc.c:378
#4  0x000000010ff940fa in GC_init_inner () at
../../../gcc-4.7-20120207/boehm-gc/misc.c:789
#5  0x000000010ff93c95 in GC_init () at
../../../gcc-4.7-20120207/boehm-gc/misc.c:493
#6  0x000000010ff8621e in libsrl_init () at
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120207/boehm-gc/testsuite/boehm-gc.lib/staticrootslib.c:26
#7  0x000000010ff2ce59 in main () at
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120207/boehm-gc/testsuite/boehm-gc.lib/staticrootstest.c:26
(gdb)

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-09 15:05:50 UTC ---
All of these crashes appear in the section in the GC_mark_from subroutine of
mark.c commented as...

       /* Try to prefetch the next pointer to be examined asap.        */
        /* Empirically, this also seems to help slightly without        */
        /* prefetches, at least on linux/X86.  Presumably this loop     */
        /* ends up with less register pressure, and gcc thus ends up    */
        /* generating slightly better code.  Overall gcc code quality   */
        /* for this loop is still not great.                            */

GC_mark_from itself is commented as...

/*
 * Mark objects pointed to by the regions described by
 * mark stack entries between GC_mark_stack and GC_mark_stack_top,
 * inclusive.  Assumes the upper limit of a mark stack entry
 * is never 0.  A mark stack entry never has size 0.
 * We try to traverse on the order of a hblk of memory before we return.
 * Caller is responsible for calling this until the mark stack is empty.
 * Note that this is the most performance critical routine in the
 * collector.  Hence it contains all sorts of ugly hacks to speed
 * things up.  In particular, we avoid procedure calls on the common
 * path, we take advantage of peculiarities of the mark descriptor
 * encoding, we optionally maintain a cache for the block address to
 * header mapping, we prefetch when an object is "grayed", etc.
 */

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #7 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-11 01:10:48 UTC ---
Interestingly, aslr randomizes the gdb crash log. For instance...

# gdb ./gctest

(gdb) break mark.c:361
Breakpoint 1 at 0x20c49ba5e20a81: file
../../../gcc-4.7-20120209/boehm-gc/mark.c, line 361.
(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/boehm-gc/testsuite/.libs/gctest 
Reading symbols for shared libraries + done
Reading symbols for shared libraries ++++........................ done

Breakpoint 1, GC_mark_some (cold_gc_frame=0x7fff6624b64c "\001") at
../../../gcc-4.7-20120209/boehm-gc/mark.c:361
361                    MARK_FROM_MARK_STACK();
(gdb) c 106
Will ignore next 105 crossings of breakpoint 1.  Continuing.

Breakpoint 1, GC_mark_some (cold_gc_frame=0x7fff6624b64c "\001") at
../../../gcc-4.7-20120209/boehm-gc/mark.c:361
361                    MARK_FROM_MARK_STACK();
(gdb) break mark.c:759
Breakpoint 2 at 0x1066722ac: file ../../../gcc-4.7-20120209/boehm-gc/mark.c,
line 759.
(gdb) c 3000
Will ignore next 2999 crossings of breakpoint 1.  Continuing.

Breakpoint 2, GC_mark_from (mark_stack_top=0x106716000, mark_stack=0x106716000,
mark_stack_limit=0x106726000) at ../../../gcc-4.7-20120209/boehm-gc/mark.c:759
759          deferred = *limit;
(gdb) c 1000
Will ignore next 999 crossings of breakpoint 2.  Continuing.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00007fff662d03d8
GC_mark_from (mark_stack_top=0x106716000, mark_stack=0x106716000,
mark_stack_limit=0x106726000) at ../../../gcc-4.7-20120209/boehm-gc/mark.c:759
759          deferred = *limit;

vs

# gdb ./gctest
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov  3 21:59:02 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries .... done

(gdb) set disable-aslr off
(gdb) break mark.c:361
Breakpoint 1 at 0x20c49ba5e20a81: file
../../../gcc-4.7-20120209/boehm-gc/mark.c, line 361.
(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/boehm-gc/testsuite/.libs/gctest 
Reading symbols for shared libraries + done
Reading symbols for shared libraries ++++........................ done

Breakpoint 1, GC_mark_some (cold_gc_frame=0x7fff605eb64c "\001") at
../../../gcc-4.7-20120209/boehm-gc/mark.c:361
361                    MARK_FROM_MARK_STACK();
(gdb) c 106
Will ignore next 105 crossings of breakpoint 1.  Continuing.

Breakpoint 1, GC_mark_some (cold_gc_frame=0x7fff605eb64c "\001") at
../../../gcc-4.7-20120209/boehm-gc/mark.c:361
361                    MARK_FROM_MARK_STACK();
(gdb) break mark.c:759
Breakpoint 2 at 0x100a112ac: file ../../../gcc-4.7-20120209/boehm-gc/mark.c,
line 759.
(gdb) c 4000
Will ignore next 3999 crossings of breakpoint 1.  Continuing.

Breakpoint 2, GC_mark_from (mark_stack_top=0x100abb000, mark_stack=0x100abb000,
mark_stack_limit=0x100acb000) at ../../../gcc-4.7-20120209/boehm-gc/mark.c:759
759          deferred = *limit;
(gdb) 

where the second attempt crosses the same number of breakpoints on mark.c:759
without crashing as in the first try.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[patrick.marlier at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

Patrick Marlier <patrick.marlier at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |patrick.marlier at gmail
                   |                            |dot com

--- Comment #8 from Patrick Marlier <patrick.marlier at gmail dot com> 2012-02-22 22:30:52 UTC ---
As discussed in https://github.com/ivmai/bdwgc/issues/13, this was fixed in
boehm-gc but due to the stage 4, I don't expect to the boehm-gc version be
upgraded. Does a workaround should be proposed?

You can try that but 1) this is untested (and probably is not enough), 2)
NO_PTHREAD_GET_STACKADDR_NP macro does not exists in current boehm-gc so
probably it will create problems too.

Index: os_dep.c
===================================================================
--- os_dep.c    (revision 184398)
+++ os_dep.c    (working copy)
@@ -1011,6 +1011,14 @@ ptr_t GC_get_stack_base()
 #if !defined(BEOS) && !defined(AMIGA) && !defined(MSWIN32) \
     && !defined(MSWINCE) && !defined(OS2) && !defined(NOSYS) && !defined(ECOS)

+# if defined(DARWIN)
+    /* We could use pthread_get_stackaddr_np even in case of a  */
+    /* single-threaded gclib (there is no -lpthread on Darwin). */
+#  include <pthread.h>
+#  undef STACKBOTTOM
+#  define STACKBOTTOM (ptr_t)pthread_get_stackaddr_np(pthread_self())
+# endif /* defined(DARWIN) */
+
 ptr_t GC_get_stack_base()
 {
 #   if defined(HEURISTIC1) || defined(HEURISTIC2) || \

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #9 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-23 02:42:47 UTC ---
(In reply to comment #8)

This change bootstraps fine with current gcc trunk on x86_64-apple-darwin11. It
almost fixes the failures in the boehm-gc test suite. The -m32 results always
pass as...

        === boehm-gc Summary for unix/-m32 ===

# of expected passes        12
# of unsupported tests        1

but often the -m64 results show the failure...

WARNING: program timed out.
FAIL: boehm-gc.c/thread_leak_test.c -O2 execution test
Running
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120222/boehm-gc/testsuite/boehm-gc.lib/lib.exp
...

        === boehm-gc Summary for unix/-m64 ===

# of expected passes        11
# of unexpected failures    1
# of unsupported tests        1

Are there any other darwin related changes upstream?

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[mikestump at comcast dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #10 from Mike Stump <mikestump at comcast dot net> 2012-02-23 04:34:30 UTC ---
The proposed patch is wrong, the code is in
boehm-gc/include/private/gcconfig.h, so the patch should change the ifdef
DARWIN block there.  I don't know why they have NO_PTHREAD_GET_STACKADDR_NP,
so, I can't guess why they have it, though, I would be interested in their
experience with it.  Anyway, propose a patch for gcconfig.h and I would likely
approve it.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[mikestump at comcast dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #11 from Mike Stump <mikestump at comcast dot net> 2012-02-23 04:56:55 UTC ---
Ah, the better way to do that would be to have:

AC_CHECK_FUNCS([pthread_get_stackaddr_np])

in configure.ac, and then just have

#ifdef HAVE_PTHREAD_GET_STACKADDR_NP
#define STACKBOTTOM (ptr_t)pthread_get_stackaddr_np(pthread_self())
#endif

This should cover all the issues with NO_PTHREAD...

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #12 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-23 15:07:17 UTC ---
(In reply to comment #11)
> Ah, the better way to do that would be to have:
> 
> AC_CHECK_FUNCS([pthread_get_stackaddr_np])
> 
> in configure.ac, and then just have
> 
> #ifdef HAVE_PTHREAD_GET_STACKADDR_NP
> #define STACKBOTTOM (ptr_t)pthread_get_stackaddr_np(pthread_self())
> #endif
> 
> This should cover all the issues with NO_PTHREAD...

Where do you want the second change made? Should I place that in
include/gc_config.h.in (which only contains #undefs right now) or in
include/gc_config_macros.h or in os_dep.c?  I notice that
HAVE_PTHREAD_GETATTR_NP is only used in pthread_support.c. The rest of the
patch looks like...


Index: configure.ac
===================================================================
--- configure.ac    (revision 184508)
+++ configure.ac    (working copy)
@@ -380,6 +380,7 @@ esac
 oldLIBS="$LIBS"
 LIBS="$LIBS $THREADLIBS"
 AC_CHECK_FUNCS([pthread_getattr_np])
+AC_CHECK_FUNCS([pthread_get_stackaddr_np])
 LIBS="$oldLIBS"

 # Configuration of machine-dependent code
Index: include/gc_config.h.in
===================================================================
--- include/gc_config.h.in    (revision 184508)
+++ include/gc_config.h.in    (working copy)
@@ -87,6 +87,9 @@
 /* Define to 1 if you have the `pthread_getattr_np' function. */
 #undef HAVE_PTHREAD_GETATTR_NP

+/* Define to 1 if you have the `pthread_get_stackaddr_np_np' function. */
+#undef HAVE_PTHREAD_GET_STACKADDR_NP
+
 /* Define to 1 if you have the <stdint.h> header file. */
 #undef HAVE_STDINT_H

Index: configure
===================================================================
--- configure    (revision 184508)
+++ configure    (working copy)
@@ -15141,6 +15141,17 @@ _ACEOF
 fi
 done

+for ac_func in pthread_get_stackaddr_np
+do :
+  ac_fn_c_check_func "$LINENO" "pthread_get_stackaddr_np"
"ac_cv_func_pthread_get_stackaddr_np"
+if test "x$ac_cv_func_pthread_get_stackaddr_np" = x""yes; then :
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_PTHREAD_GET_STACKADDR_NP 1
+_ACEOF
+
+fi
+done
+
 LIBS="$oldLIBS"

 # Configuration of machine-dependent code

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-02-23
     Ever Confirmed|0                           |1

--- Comment #13 from Iain Sandoe <iains at gcc dot gnu.org> 2012-02-23 15:16:57 UTC ---
(In reply to comment #9)
> (In reply to comment #8)

> but often the -m64 results show the failure...
> 
> WARNING: program timed out.
> FAIL: boehm-gc.c/thread_leak_test.c -O2 execution test
> Running
> /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120222/boehm-gc/testsuite/boehm-gc.lib/lib.exp

This (random) fail is also seen on x86-d9/d10 - so not something related to the
pie shifts.

I've not had time to investigate - but suspect  it is related to operating
close to stack limits -- if you try reducing the number of recursions (like PPC
does) does this go away?

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[patrick.marlier at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #14 from Patrick Marlier <patrick.marlier at gmail dot com> 2012-02-23 15:32:31 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> 
> This change bootstraps fine with current gcc trunk on x86_64-apple-darwin11. It
> almost fixes the failures in the boehm-gc test suite. The -m32 results always
> pass as...
> 
>         === boehm-gc Summary for unix/-m32 ===
> 
> # of expected passes        12
> # of unsupported tests        1
> 
> but often the -m64 results show the failure...
> 
> WARNING: program timed out.
> FAIL: boehm-gc.c/thread_leak_test.c -O2 execution test
> Running
> /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120222/boehm-gc/testsuite/boehm-gc.lib/lib.exp
> ...
> 
>         === boehm-gc Summary for unix/-m64 ===
> 
> # of expected passes        11
> # of unexpected failures    1
> # of unsupported tests        1
> 
> Are there any other darwin related changes upstream?
I also notice this failure on x86_64 linux. In my case, it is due to the
redefinition of GC_LINUX_THREADS.

./boehm-gc/include/gc_config.h:44:0: warning: "GC_LINUX_THREADS" redefined
[enabled by default]^M
./boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:1:0: note: this is the
location of the previous definition

What does the log tell you?

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[patrick.marlier at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #16 from Patrick Marlier <patrick.marlier at gmail dot com> 2012-02-23 15:49:26 UTC ---
Created attachment 26735
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26735
proposal fix

I have also started a patch (not tested at all) but I am more extreme in the
approach and confines the change to boehm-gc and darwin x86/x86_64 (Lion
doesn't support PPC, right?). Does the change to x86 is required? I am not
sure...
This is a workaround for 4.7 but I think boehm-gc should be updated for 4.8?
Jack/Iain/Mike, I think it is wise to let you fix it since I have no access to
a darwin11.

        PR boehm-gc/52179
        * include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with
        pthread_get_stackaddr_np when available.
        * configure.ac (THREADS): Check availability of
        pthread_get_stackaddr_np on *-*-darwin*.
        * configure: Regenerate.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #15 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-23 15:49:06 UTC ---
I notice in boehm-gc/include/private/gcconfig.h we are already setting...

#   ifdef DARWIN
#     define OS_TYPE "DARWIN"
#     define DYNAMIC_LOADING
#     if defined(__ppc64__)
#       define ALIGNMENT 8
#       define CPP_WORDSZ 64
#       define STACKBOTTOM ((ptr_t) 0x7fff5fc00000)
#       define CACHE_LINE_SIZE 64
#       ifndef HBLKSIZE
#         define HBLKSIZE 4096
#       endif
#     else
#       define ALIGNMENT 4
#       define STACKBOTTOM ((ptr_t) 0xc0000000)
#     endif

so I guess we just want to append

#ifdef HAVE_PTHREAD_GET_STACKADDR_NP
#define STACKBOTTOM (ptr_t)pthread_get_stackaddr_np(pthread_self())
#endif

at the end of those lines

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #17 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-23 18:24:16 UTC ---
Created attachment 26737
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26737
reduced patch

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #18 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-23 18:31:10 UTC ---
(In reply to comment #16)

The reduced patch properly adds the..

/* Define to 1 if you have the `pthread_get_stackaddr_np_np' function. */
 #undef HAVE_PTHREAD_GET_STACKADDR_NP

to boehm-gc/include/gc_config.h.in .

 Since the remaining changes to boehm-gc/include/private/gcconfig.h are "#  
ifdef DARWIN"
and  HAVE_PTHREAD_GET_STACKADDR_NP exists no where else, this should be
sufficient.
The patch elimintes the failures at -m32/-m64 on x86_64-apple-datrwin11 but
boehm-gc.c/thread_leak_test.c execution test still hangs on occasion at -m64.
This appears as...

Leaked composite object at 0x10a908fe0
(/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120223/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:12,
sz=4, NORMAL)

Leaked composite object at 0x10a908ec0
(/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120223/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:12,
sz=4, NORMAL)

Leaked composite object at 0x10a908f20
(/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120223/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:12,
sz=4, NORMAL)

Leaked composite object at start: 0x10a908f00, appr. length: 48

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #19 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-23 18:37:40 UTC ---
(In reply to comment #13)
> I've not had time to investigate - but suspect  it is related to operating
> close to stack limits -- if you try reducing the number of recursions (like PPC
> does) does this go away?

This is a different test. On x86_64-apple-darwin11, it is thread_leak_test.c
which fails the execution test, not gctest.c or leak_test.c. I'll try
rebuilding gcc trunk with the reduced patch but without...


------------------------------------------------------------------------
r175182 | mrs | 2011-06-18 11:06:26 -0400 (Sat, 18 Jun 2011) | 4 lines

        PR target/49461

        * libjava/configure.ac (SYSTEMSPEC): Pass -no_pie for darwin11.
        * libjava/configure: Regenerate.

to see how the libjava tests behave now with -pie.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[mikestump at comcast dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #20 from Mike Stump <mikestump at comcast dot net> 2012-02-23 18:45:28 UTC ---
> Where do you want the second change made?

Let me repeat myself:

the code is in boehm-gc/include/private/gcconfig.h, so the patch should change
the ifdef
DARWIN block there.


In the code in the file I mentioned, as a replacement to the #define that
exists today.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #21 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-23 18:50:21 UTC ---
(In reply to comment #20)
> > Where do you want the second change made?
> 
> Let me repeat myself:
> 
> the code is in boehm-gc/include/private/gcconfig.h, so the patch should change
> the ifdef
> DARWIN block there.
> 
> 
> In the code in the file I mentioned, as a replacement to the #define that
> exists today.

Yes, See the reduced patch I posted in comment 17. Also, if thread_leak_test.c
is twitchy with -pie at -m64, we could also open a PR for that and just skip
this test on darwin11+ at -m64 for now. Assuming that my proposed reversion of
r175182 causes no regressions in libjava on darwin11+.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[patrick.marlier at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #22 from Patrick Marlier <patrick.marlier at gmail dot com> 2012-02-23 18:52:56 UTC ---
(In reply to comment #21)
> (In reply to comment #20)
> > > Where do you want the second change made?
> > 
> > Let me repeat myself:
> > 
> > the code is in boehm-gc/include/private/gcconfig.h, so the patch should change
> > the ifdef
> > DARWIN block there.
> > 
> > 
> > In the code in the file I mentioned, as a replacement to the #define that
> > exists today.
> 
> Yes, See the reduced patch I posted in comment 17. Also, if thread_leak_test.c
> is twitchy with -pie at -m64, we could also open a PR for that and just skip
> this test on darwin11+ at -m64 for now. Assuming that my proposed reversion of
> r175182 causes no regressions in libjava on darwin11+.

It seems there is already a PR for thread_leak_test.c failure:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299

Patrick.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[mikestump at comcast dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #23 from Mike Stump <mikestump at comcast dot net> 2012-02-23 18:56:31 UTC ---
I think the patch in 17 is Ok.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #24 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-23 20:13:06 UTC ---
Created attachment 26739
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26739
fix both PR52179 and revert hack from PR49461

I propose the following patch which both fixes PR52179 and reverts r175182
since it is no longer need. This patch bootstraps on x86_64-apple-darwin11 and
produces the expected darwin11 libjava results without passing -Wl,-no_pie to
the linker in gcj on darwin11.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[mikestump at comcast dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #25 from Mike Stump <mikestump at comcast dot net> 2012-02-23 21:53:04 UTC ---
Ok.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #26 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-23 21:55:57 UTC ---
Posted to gcc-patches as
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01209.html.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[pmarlier at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #27 from pmarlier at gcc dot gnu.org 2012-02-24 15:21:20 UTC ---
Author: pmarlier
Date: Fri Feb 24 15:21:12 2012
New Revision: 184555

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184555
Log:
2012-02-23  Patrick Marlier  <patrick.marlier@gmail.com>
        Jack Howarth  <howarth@bromo.med.uc.edu>

boehm-gc/

    PR boehm-gc/52179
    * include/gc_config.h.in: Undefine HAVE_PTHREAD_GET_STACKADDR_NP.
    * include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with
    pthread_get_stackaddr_np when available.
    * configure.ac (THREADS): Check availability of pthread_get_stackaddr_np.
    * configure: Regenerate.

libjava/

    PR target/49461
    * configure.ac (SYSTEMSPEC): No longer pass -no_pie for darwin11.
    * configure: Regenerate.


Modified:
    trunk/boehm-gc/ChangeLog
    trunk/boehm-gc/configure
    trunk/boehm-gc/configure.ac
    trunk/boehm-gc/include/gc_config.h.in
    trunk/boehm-gc/include/private/gcconfig.h
    trunk/libjava/ChangeLog
    trunk/libjava/configure
    trunk/libjava/configure.ac

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

Jack Howarth <howarth at nitro dot med.uc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #28 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-29 03:53:50 UTC ---
Fixed at r184555.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

--- Comment #29 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2012-03-02 18:21:46 UTC ---
Author: mrs
Date: Fri Mar  2 18:21:41 2012
New Revision: 184809

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184809
Log:
2012-03-02  Jack Howarth  <howarth@bromo.med.uc.edu>

    Backport from mainline
    2012-02-23  Patrick Marlier  <patrick.marlier@gmail.com>
            Jack Howarth  <howarth@bromo.med.uc.edu>

    PR boehm-gc/52179
    * include/gc_config.h.in: Undefine HAVE_PTHREAD_GET_STACKADDR_NP.
    * include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with
    pthread_get_stackaddr_np when available.
    * configure.ac (THREADS): Check availability of
    pthread_get_stackaddr_np.
    * configure: Regenerate.

2012-03-02  Jack Howarth  <howarth@bromo.med.uc.edu>

    Backport from mainline
    2012-02-23  Patrick Marlier  <patrick.marlier@gmail.com>
               Jack Howarth  <howarth@bromo.med.uc.edu>

    PR target/49461
    * configure.ac (SYSTEMSPEC): No longer pass -no_pie for darwin11.
    * configure: Regenerate.

Modified:
    branches/gcc-4_6-branch/boehm-gc/ChangeLog
    branches/gcc-4_6-branch/boehm-gc/configure
    branches/gcc-4_6-branch/boehm-gc/configure.ac
    branches/gcc-4_6-branch/boehm-gc/include/gc_config.h.in
    branches/gcc-4_6-branch/boehm-gc/include/private/gcconfig.h
    branches/gcc-4_6-branch/libjava/ChangeLog
    branches/gcc-4_6-branch/libjava/configure
    branches/gcc-4_6-branch/libjava/configure.ac

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu.org
      Known to work|                            |4.6.4, 4.7.0

--- Comment #30 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2012-03-02 18:35:01 UTC ---
Fixed in 4.6.4 and 4.7.0.