I assume nothing is prelinked? I don't think that was even an option on RedHat 7.1.
It would be helpful to set a breakpoint in GC_add_roots_inner, and verify that it's actually being called with (DATAEND, which is defined to be) _end as its middle argument. It looks like both mono and libmono define _end. By the normal ELF default symbol lookup rules, I believe libmono references to _end should see the definition in the main program. If this is indeed not happening, and if the libmono developers aren't aware of other relevant issues, I would ask on a binutils mailing list for ideas. Hans > -----Original Message----- > From: Nikolai Zhubr [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 04, 2004 12:53 PM > To: Boehm, Hans > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: GC issue in mono 0.31 > > > Hello Hans, > I think my binutils are just of regular Redhat 7.1 linux: > binutils-2.10.91.0.2-3 > GNU ld 2.10.91 > Copyright 2001 Free Software Foundation, Inc. > I've just checked, there are no occurencies of "Bsymbolic" > anywhere within mono build tree. > The output of nm is attached. > -- > Best regards, > Nikolai Zhubr > Tuesday, 04 May, 2004, 1:41:32, you wrote: > > The problem is pretty clear: The GC is treating the region > > between __data_start (0x80497b0) and the end of the libmono > data segment > > (0x401851a0) as a single traceable data region. That probably means > > _end is somehow defined by the linker to be the end of the libmono > > data segment instead of the end of the main data segment. This > > is not how Linux linkers are supposed to behave, though I've > > seen similar behavior on other operating systems. (This > assumes that > > libmono doesn't use some other mechanism for setting DATAEND.) > > If your binutils and linker script came from a standard > Linux distribution, > > it would be nice to track down how this happened. If not, > that's almost > > certainly the source of the problem. > > Another possible cause of the problem might be if the gc is > linked into > > libmono, and that's linked with -Bsymbolic. (That's probably > > not an unreasonable thing to do. If so, there's probably a way to > > work around this.) > > The output of nm on the main executable and libmono might be useful > > in tracking this down further. > > Hans > _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list