RE: Solaris/X86 GC issues (was /bin/sh portability issues ...)

["Boehm, Hans" <hans dot boehm at hp dot com>]

Sorry about the typo in the previous subject.  Reposting to make
searches work.

Hans

> -----Original Message-----
> From: java-patches-owner@gcc.gnu.org 
> [mailto:java-patches-owner@gcc.gnu.org] On Behalf Of Boehm, Hans
> Sent: Friday, July 07, 2006 3:45 PM
> To: Roger Sayle; Rainer Orth
> Cc: java-patches@gcc.gnu.org; gcc-patches@gcc.gnu.org; 
> gc@linux.hpl.hp.com
> Subject: Solaris/X96 GC issues (was /bin/sh portability issues ...)
> 
> I checked Rainer's patch into the 7.0 tree, and added it to my current
> 6.8 tree.  Thanks.
> 
> That doesn't help with the Studio 11 cc problems that Rainer 
> reported earlier.  Someone with access to a suitable machine 
> will have to track those down.  The next step is to identify 
> which objects are getting prematurely collected and why.  It 
> would be useful to see whether the offending list is 
> referenced by an automatic or static pointer.  In either 
> case, it is also worth checking that 
> GC_with_callee_saves_pushed ends up calling getcontext(), as 
> it should.  If it is a static pointer, and getcontext() is 
> called correctly, I would next check that roots are being 
> registered correctly, and the offending pointer is in a root 
> segment.  Setting the GC_DUMP_REGULARLY environment variable 
> prints roots on a regular basis.
> 
> It is possible that the studio 11 issue also affects gcc, but 
> just happened to not be exercised.
> 
> I think the GC_register_has_static_roots_callback issue was 
> libjava-specific, since I hadn't gotten around to putting the 
> patch that introduced it into the CVS tree.  (I just 
> corrected that).  It should be defined in dyn_load.c, though 
> it would be undefined if DYNAMIC_LOADING somehow didn't get 
> defined in gcconfig.h.  (That's probably not the way things 
> should work.  I made it a noop in that case for 7.0.  But the 
> real problem is probably in your gcconfig.h.)
> 
> Slightly longer term, I'm not sure about the right path.  I 
> don't really have enough cycles to work on 7.0, so I don't 
> expect to spend time on 6.8, except for relatively small and 
> critical patches.  If someone can generate a 6.8 patch to 
> make Solaris/X86 work, I'm certainly fine with just putting 
> it into gcc.  I suspect it would be big enough to be problematic.
> 
> Overall, my vote would be for
> 
> 1) Making 7.0 work reliably on Solaris/X86.  (I have been 
> testing occasionally on Solaris/SPARC, and it seems OK there.)
> 2) Merging 7.0 into 4.3 early in that cycle.  My expectation 
> is that that would generate some breakage, mostly on less 
> common platforms.  But on platforms like Linux, I think 7.0 
> is actually now fairly stable.
> 
> Hans
> 
> > -----Original Message-----
> > From: java-patches-owner@gcc.gnu.org
> > [mailto:java-patches-owner@gcc.gnu.org] On Behalf Of Roger Sayle
> > Sent: Friday, July 07, 2006 6:25 AM
> > To: Rainer Orth
> > Cc: java-patches@gcc.gnu.org; gcc-patches@gcc.gnu.org
> > Subject: Re: [JAVA] /bin/sh portability issues in 
> > scripts/check_jni_methods.sh
> > 
> > 
> > On 7 Jul 2006, Rainer Orth wrote:
> > > Roger Sayle <roger@eyesopen.com> writes:
> > > > terminating with a hard error, and enables libjava to reach the 
> > > > application linking steps at the end of the build (which
> > suffer from
> > > > boehmgc issues that I may not have resolved correctly).
> > >
> > > This is probably PR boehm-gc/21942.
> > > I've recently sent a new message about this to the boehm-gc list:
> > > 
> > 
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2006-June/001334.h
> > > tml
> > 
> > Cool!  Yes, this exactly the issue and your patch above is nearly 
> > identical to the one I have in my tree to allow the build to reach 
> > libjava.  Unfortunately, I'm seeing a unresolved symbol 
> reference to 
> > GC_register_has_static_roots_callback from libgcj.so when 
> attempting 
> > to link jv-convert, so I wasn't sure if it was my
> > X86_64/SUNOS5 changes in boehmgc/include/private/gcconfig.h
> > that were at fault, or another latent problem in the libjava build 
> > system.
> > 
> > Anyway, thanks again for pointing out that you're on top of this 
> > particular issue (one less thing for me to worry about).
> >  Hopefully, Hans will comment soon.  I did check the 
> upstream sources 
> > to see if it was just an import of the latest boehmgc that was 
> > required.
> > 
> > Thanks again for addressing this.
> > 
> > Roger
> > --
> > 
> > 
>