This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Re: GC_data_start
- To: "Boehm, Hans" <hboehm at exch dot hpl dot hp dot com>
- Subject: Re: GC_data_start
- From: Jeff Sturm <jsturm at sigma6 dot com>
- Date: Wed, 17 Nov 1999 19:24:43 -0500
- CC: "'Tom Tromey'" <tromey at cygnus dot com>, java-discuss at sourceware dot cygnus dot com
- Organization: AppNet
- References: <34E36C05935CD311AE5000A0C9B6B0BF011A155E@hplex3.hpl.hp.com>
But the symbol ".data" still resolves to a different address in each
shared object. Try it... I think it'll give the same answer as the
GC_find_limit(&GC_copyright) techique.
Corey Minyard wrote to say that defining __data_start was considered a
mistake and will disappear from future glibc releases, Intel too. He
also says the symbol "data_start" is a weak symbol and takes its
place... it works fine on my Intel RH6.0 box. I'm going to try it on my
Alpha tonight.
Failing that, Tom's suggestion to look at the ELF header is a good
one... the same approach used in dyn_load.c may work for the main
executable.
"Boehm, Hans" wrote:
> I just asked David Mosberger here. He points out that the symbold ".data"
> is still defined on demand, and can be accessed with
>
> footype foo asm(".data");
>
> I'm using that for now for all Linux platforms. I would guess it's roughly
> as brittle as the other solutions, but it's less (i.e. no) code.
--
Jeff Sturm
jsturm@sigma6.com