GC_data_start

[Boehm, Hans]

I don't recall seeing the /proc-based code before.  My version 4.13 used
__data_start.  This used to be defined by the linker or glibc, but
disappeared somewhere along the way.  The GC_find_limit approach was put in
as a replacement.  But I agree that it has problems.

My only problem with the /proc-based solution here is that it's a fair
amount of fairly brittle code to accomplish something that should be
trivial, and used to be trivial.  (Reading the stack base, in contrast, is a
small amount of slightly less brittle, and completely different, code.) I
would prefer to see glibc or ld consistently define a symbol that maps to
the beginning of the data segment.  As far as I can tell, ld does this on
Linux/X86, but not on some other platforms.  Does anybody know why?  Any
chance of getting this fixed?

Hans

-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Monday, November 15, 1999 9:01 PM
To: java-discuss@sourceware.cygnus.com
Subject: GC_data_start



Since the new boehm-gc code was imported into libgcj, shared builds no
longer work on my Alpha.  Some investigation reveals that the
GC_data_start address is calculated (with GC_find_limit) from the
GC_copyright symbol.  The trouble is that shared builds don't locate
GC_copyright in the main data segment.

The previous release used /proc to discover the boundaries of the data
segment.  That worked on Alpha for static and shared builds.  The same
technique should also work on Sparc and PPC (and Intel for that matter),
though I have no way of testing all of those.  (It's similar to the new
/proc code to reliably determine the stack bottom; perhaps these can be
merged.)

The GC_find_limit trick isn't useable since I can't find a symbol that is
guaranteed to exist in the data segment.  Does anybody object to reverting
to the old /proc-based code, or have any better ideas?

--
Jeff Sturm
jsturm@sigma6.com