[Gc] [Fwd: [Fwd: [PATCH] Fix boehm-gc build on Cygwin]]

[Andrew Haley]

OK to commit?

Andrew.

[Ivan Maidanski]

Hi!

Post by Andrew Haley
OK to commit?
Andrew.
Hi all,
Boehm-gc doesn't currently build correctly on Cygwin; it's ok for objc, but
/gnu/gcc/gcc/boehm-gc/misc.c:680: undefined reference to
`_GC_get_thread_stack_base'
collect2: ld returned 1 exit status
make[3]: *** [libgcj.la] Error 1

What's GC version? I guess prior to 6.8 (GC_get_thread_stack_base is not used at present).

Not sure for CVS version but with my pending patches, it could be built for Cygwin and works (including thread-local-alloc and parallel marking, but except for memory unmapping in the threaded case). Although, I can't say I've tested it much (unlike for MinGW). Not tested with GCJ directly but GCJ functionality of GC itself works OK.

Also, not sure for building scripts be up to date, I'm direct directly calling gcc like this:

gcc -O2 -fno-strict-aliasing -Wall -DNO_EXECUTE_PERMISSION -DALL_INTERIOR_POINTERS -DJAVA_FINALIZATION -DGC_GCJ_SUPPORT -DATOMIC_UNCOLLECTABLE -DNO_DEBUGGING -DLARGE_CONFIG -DGC_THREADS -DTHREAD_LOCAL_ALLOC -DPARALLEL_MARK -DNDEBUG -I include -I libatomic_ops-1.2/src -DGC_BUILD -DGC_DLL -shared -o gc.dll -s *.c *.cc

To get a working copy either fetch latest CVS and apply my Cygwin-specific patches, or use this snapshot:
http://www.ivmaisoft.com/sources/jcgo/bdwgc72a1-20090515-ivmai.tar.bz2

Post by Andrew Haley
With the attached patch (which I've had in my local tree for some time now),
Completed 3 tests
Allocated 5694334 collectable objects
Allocated 306 uncollectable objects
Allocated 3557803 atomic objects
Allocated 34418 stubborn objects
Finalized 6603/6603 objects - finalization is probably ok
Total number of bytes allocated is 192747548
Final heap size is 16338944 bytes
Collector appears to work
Completed 137 collections
PASS: gctest
==================
All 1 tests passed
==================
Tested by building (non-bootstrap, since this is a target lib) with
--enable-languages=c,c++,java, and running check-target-boehm-gc.
* win32_threads.c (GC_get_thread_stack_base): Implement for Cygwin.
Ok?
cheers,
DaveK

Bye.

[Andrew Haley]

Post by Ivan Maidanski
Hi!

Hi upstream!

Post by Ivan Maidanski

Post by Andrew Haley
OK to commit?
Andrew.
Hi all,
Boehm-gc doesn't currently build correctly on Cygwin; it's ok for objc,
but libjava wants to use an interface that isn't currently fully
../boehm-gc/.libs/libgcjgc_convenience.a(misc.o): In function
`GC_init_inner': /gnu/gcc/gcc/boehm-gc/misc.c:680: undefined reference to
`_GC_get_thread_stack_base' collect2: ld returned 1 exit status
make[3]: *** [libgcj.la] Error 1

What's GC version? I guess prior to 6.8 (GC_get_thread_stack_base is not
used at present).

Yes, it's the version in-tree in GCC. I took a look at the cvsweb at
sourceforge (bdwgc) and it looked to me like the function had been eliminated
on your HEAD which is why I only sent it to gcc lists.

Post by Ivan Maidanski
Not sure for CVS version but with my pending patches, it could be built for
Cygwin and works

Andrew, I'd much rather add this trivial patch to our in-tree version than
think about importing a new version and disturbing every target under the sun,
can we just fix it locally?

OK.

Andrew.

[Dave Korn]

Andrew, I'd much rather add this trivial patch to our in-tree version than
think about importing a new version and disturbing every target under the sun,
can we just fix it locally?

OK.

Thanks. Updated, bubblestrapped and retested, and applied at r147641.

Ivan, re: your query about synching gcc and bdwgc a bit better, it's not
something I can offer help with (I have a list as long as my arm of things
that plain don't work to fix at the moment), but I noted that there's been
some people looking into this in the fairly-recent past:

http://gcc.gnu.org/wiki/GCTuningApplication
http://gcc.gnu.org/wiki/Garbage_collection_tuning
http://gcc.gnu.org/wiki/BoehmGCForGCC
http://gcc.gnu.org/svn.html#devbranches - see boehms-gc, gc-improv.

Laurynas Biveinis probably knows more about GC in GCC than anyone else,
although I don't know how busy he might or might not be, but maybe you can get
some co-ordination going between yourselves and the folks who've worked on
those branches.

cheers,
DaveK

[Dave Korn]

Post by Ivan Maidanski
Hi!

Hi upstream!

Post by Ivan Maidanski

Post by Andrew Haley
OK to commit?
Andrew.
Hi all,
Boehm-gc doesn't currently build correctly on Cygwin; it's ok for objc,
but libjava wants to use an interface that isn't currently fully
../boehm-gc/.libs/libgcjgc_convenience.a(misc.o): In function
`GC_init_inner': /gnu/gcc/gcc/boehm-gc/misc.c:680: undefined reference to
`_GC_get_thread_stack_base' collect2: ld returned 1 exit status
make[3]: *** [libgcj.la] Error 1

What's GC version? I guess prior to 6.8 (GC_get_thread_stack_base is not used at present).

Yes, it's the version in-tree in GCC. I took a look at the cvsweb at
sourceforge (bdwgc) and it looked to me like the function had been eliminated
on your HEAD which is why I only sent it to gcc lists.

Post by Ivan Maidanski
Not sure for CVS version but with my pending patches, it could be built for
Cygwin and works

Andrew, I'd much rather add this trivial patch to our in-tree version than
think about importing a new version and disturbing every target under the sun,
can we just fix it locally?

cheers,
DaveK

[Boehm, Hans]

Unles someone can think of a reason this is silly, I'll check the following into the upstream sources, so that
we at least don't lose the code. I suspect that what we currently do is worse.

Note that this currently just removes some obsolete comments which appear to be inaccurate, and adds
ifdef'ed out code, which would need to be tested and enabled under the right conditions.

Hans.

Index: os_dep.c
===================================================================
RCS file: /cvsroot/bdwgc/bdwgc/os_dep.c,v
retrieving revision 1.36
diff -u -r1.36 os_dep.c
--- os_dep.c 16 Mar 2009 23:53:10 -0000 1.36
+++ os_dep.c 18 May 2009 22:40:45 -0000
@@ -621,12 +621,6 @@
# endif
# endif

-/*
- * Find the base of the stack.
- * Used only in single-threaded environment.
- * With threads, GC_mark_roots needs to know how to do this.
- * Called with allocator lock held.
- */
# if defined(MSWIN32) || defined(MSWINCE) \
|| (defined(CYGWIN32) && !defined(USE_MMAP))
# define is_writable(prot) ((prot) == PAGE_READWRITE \
@@ -665,6 +659,19 @@
return GC_SUCCESS;
}

+#if 0
+
+/* An alternate version for Cygwin might be */
+/* (adapted from Dave Korn for gcc version, untested): */
+GC_API int GC_CALL GC_get_stack_base(struct GC_stack_base *sb)
+{
+ extern GC_PTR _tlsbase __asm__ ("%fs:4");
+ sb -> mem_base = _tls_base;
+ return GC_SUCCESS;
+}
+
+#endif /* 0 */
+
#define HAVE_GET_STACK_BASE

/* This is always called from the main thread. */

-----Original Message-----
Sent: Sunday, May 17, 2009 5:13 AM
To: Ivan Maidanski
Subject: [Gc] Re: [Fwd: [PATCH] Fix boehm-gc build on Cygwin]

Post by Ivan Maidanski
Hi!

Hi upstream!

Post by Ivan Maidanski

Post by Andrew Haley
OK to commit?
Andrew.
Hi all,
Boehm-gc doesn't currently build correctly on Cygwin; it's ok for
objc, but libjava wants to use an interface that isn't currently
fully
../boehm-gc/.libs/libgcjgc_convenience.a(misc.o): In function
`GC_init_inner': /gnu/gcc/gcc/boehm-gc/misc.c:680: undefined
reference to `_GC_get_thread_stack_base' collect2: ld returned 1
exit status
make[3]: *** [libgcj.la] Error 1

What's GC version? I guess prior to 6.8

(GC_get_thread_stack_base is

Post by Ivan Maidanski
not used at present).

Yes, it's the version in-tree in GCC. I took a look at the
cvsweb at sourceforge (bdwgc) and it looked to me like the
function had been eliminated on your HEAD which is why I only
sent it to gcc lists.

Post by Ivan Maidanski
Not sure for CVS version but with my pending patches, it could be
built for Cygwin and works

Andrew, I'd much rather add this trivial patch to our
in-tree version than think about importing a new version and
disturbing every target under the sun, can we just fix it locally?
cheers,
DaveK
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

[Ivan Maidanski]

Hi!

Unless someone can think of a reason this is silly, I'll check the following into the upstream sources, so that
we at least don't lose the code. I suspect that what we currently do is worse.

It seems that You're right. At least, it seems it removes "Thread stack pointer ... out of range, pushing everything" warning (in case of USE_MMAP).

Ok to commit it (even with some typos) now. I'll test (in the major configs) and submit changes integrating it permanently (with some more Cygwin-specific changes) shortly.

Note that this currently just removes some obsolete comments which appear to be inaccurate, and adds
ifdef'ed out code, which would need to be tested and enabled under the right conditions.
Hans.
...

-----Original Message-----
Sent: Sunday, May 17, 2009 5:13 AM
To: Ivan Maidanski
Subject: [Gc] Re: [Fwd: [PATCH] Fix boehm-gc build on Cygwin]

Hi!

Hi upstream!

Post by Andrew Haley
OK to commit?
Andrew.
Hi all,
Boehm-gc doesn't currently build correctly on Cygwin; it's ok for
objc, but libjava wants to use an interface that isn't currently
fully
...

Bye.

[Dave Korn]

Post by Ivan Maidanski
Hi!

Unless someone can think of a reason this is silly, I'll check the
following into the upstream sources, so that we at least don't lose the
code. I suspect that what we currently do is worse.

It seems that You're right. At least, it seems it removes "Thread stack
pointer ... out of range, pushing everything" warning (in case of
USE_MMAP).

Just to explain how it works: the %fs segment in windows always points to a
block of thread-specific data called "struct NT_TIB" that contains pointers to
the stack limits for the thread.

http://en.wikipedia.org/wiki/Win32_Thread_Information_Block

Note that that description is a bit confusing, it uses "Top" of stack to
mean the highest memory end and "Bottom" to describe the moving lowest memory
end pointed to by $esp[*]

The reason for the references to TLS in the code is because it is modelled
on the code from the Cygwin DLL that locates the TLS area, which Cygwin
maintains in memory just above the high end of the stack.

http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/how-cygtls-works.txt?cvsroot=src
[ or http://tinyurl.com/how-cygtls-works to avoid wrapping ]

So, the value returned is exactly one byte after the highest byte of the
stack, i.e. if the stack is located in the 64k page from 0x220000 to 0x22ffff
then the return value is 0x230000. I wasn't sure whether to subtract one or
not, I'm sure you guys will know whether that's the right thing to do. (I
figured it probably wouldn't matter for the purposes of bounds-checking
whether something came from the stack or not anyway.)

cheers,
DaveK