[Gc] problem with boehm-gc on NetBSD/m68k

Hubert Feyrer hubert at feyrer.de
Fri Apr 2 07:41:04 PST 2004


I don't know if NetBSD/m68k has writable area for shared libraries (I sort
of doubt it, but can't tell for sure). Commenting out the change with the
patch below, I get:

        serpens% gmake check-TESTS
        Completed 1 tests
        Allocated 648021 collectable objects
        Allocated 101 uncollectable objects
        Allocated 1250000 atomic objects
        Allocated 10880 stubborn objects
        Finalized 2206/2206 objects - finalization is probably ok
        Total number of bytes allocated is 60879460
        Final heap size is 5414912 bytes
        Collector appears to work
        PASS: gctest
        ==================
        All 1 tests passed
        ==================

Does that look ok enough?


 - Hubert

--- tests/test.c.orig   Fri Apr  2 17:30:34 2004
+++ tests/test.c        Fri Apr  2 17:33:05 2004
@@ -1256,7 +1256,7 @@
        FAIL;
       }
       if (!TEST_FAIL_COUNT(1)) {
-#      if!(defined(RS6000) || defined(POWERPC) || defined(IA64))
+#      if!(defined(RS6000) || defined(POWERPC) || defined(IA64) ||defined(M68K)
)
          /* ON RS6000s function pointers point to a descriptor in the  */
          /* data segment, so there should have been no failures.       */
          (void)GC_printf0("GC_is_visible produced wrong failure indication\n");


On Wed, 31 Mar 2004, Boehm, Hans wrote:
> I'm not sure whether this is a serious error.
>
> I suspect the problem is that
> GC_is_visible(y), where y is a function pointer, does not invoke
> GC_is_visible_print_proc(), which indicates that the collector thought that
> function pointers point to a valid root segment that should be scanned.
>
> On some platforms, this is indeed correct, because function pointers really
> point to a function descriptor in the static data area.  Or I guess it might
> happen if the platform supports dynamic libraries but doesn't write-protect code.
> (Are there such platforms?)
>
> This is why the code that checks this (and fails for you) is not compiled on some
> architectures.  It may be that M68K just needs to be added to this list.
>
> (This is a flakey test.  But I'd rather understand the cases in which it fails
> rather than taking it out for all platforms.  It's also really testing a
> corner case rather than basic functionality.)
>
> If you know that your platform uses function descriptors in the data area,
> I will go ahead and make this change.  If you're not sure, but all other
> tests pass if you comment out this one (around line 1260 of test.c),
> I'd also be inclined to go ahead and make this change.
>
> I added the definition of USE_GENERIC_PUSH_REGS.  I think the rest of the
> NetBSD patch is already in my latest versions.
>
> Hans
>
> > -----Original Message-----
> > From: gc-bounces at napali.hpl.hp.com
> > [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Hubert Feyrer
> > Sent: Wednesday, March 31, 2004 1:46 PM
> > To: gc at napali.hpl.hp.com
> > Subject: [Gc] problem with boehm-gc on NetBSD/m68k
> >
> >
> >
> > Hi,
> >
> > we can't seem to get boehm-gc build properly on the M68K platform in
> > NetBSD, and lacking some intimate understanding of the internals this
> > seems not possible to fix (for me :). The problem is documented at
> > http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=23670
> > and if someone had a clue on how to get boehm-gc compiling
> > _and_ working
> > ('gmake check') on an m68k platform, that would be welcome to know.
> > I've done my debugging documented in the PR with boehm-gc 6.2 on a
> > NetBSD/amiga (m68k) platform running NetBSD 1.6.2.
> >
> > Thanks!
> >
> >
> >  - Hubert
> >
> > --
> > Hubert Feyrer <hubert at feyrer.de>
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> >
>

-- 
Hubert Feyrer <hubert at feyrer.de>


More information about the Gc mailing list