RE: Interface between gc and clients to control conservative scan

[Andrew Haley <aph at redhat dot com>]

Boehm, Hans writes:

 > My impression is that dl_phdr_info is basically linux-specific anyway?
 > Thus I'm not sure what would be gained by avoiding the weak-symbol
 > dependency.  But I may be missing something.

I don't know.  I imagine that every UNIX-like operating system which
supports DSOs must have some sort of equivalent to dl_phdr_info.

 > It would be ideal if there were a way to keep this interface
 > OS-independent, even if it's not universally implemented,
 > especially since it should be safe to ignore the registration call.
 > Would it make sense just to pass back the name and address, rather
 > than the pointer to dl_phdr_info?

That would certainly be adequate for my purposes.

 > I think my preferences would be, in order:
 > 
 > 1) Make the interface OS-independent and add the registration callback,
 > as you suggest.
 > 
 > 2) Leave it as it is, as an undocumented (to the extent that's possible
 > in open source), linux-specific hook, weak symbol and all.
 > 
 > (2) is OK, but if (1) can work, I'd try for that path.  Otherwise this
 > issue will shortly have to be revisited for various other platforms.

Very well, (1) it is.

Andrew.


 > > -----Original Message-----
 > > From: Andrew Haley [mailto:aph@redhat.com] 
 > > Sent: Thursday, April 06, 2006 3:24 AM
 > > To: Boehm, Hans
 > > Cc: java@gcc.gnu.org; gc@napali.hpl.hp.com
 > > Subject: Interface between gc and clients to control conservative scan
 > > 
 > > Hans,
 > > 
 > > I need a way to control which shared libraries are 
 > > conservatively scanned.  This is because the version of gcj 
 > > I'm working on does not require conservative scanning of 
 > > shared libraries, whereas old gcj-compiled libraries do.  We 
 > > need to be able to interwork with these old libraries.
 > > 
 > > In my current work I'm using a version of 
 > > GC_register_dynlib_callback like this:
 > > 
 > > 
 > > int (*GC_has_static_roots)(struct dl_phdr_info * info, size_t 
 > > size, void *ptr)
 > >   __attribute__((weak));
 > > 
 > > static int GC_register_dynlib_callback(info, size, ptr)
 > >      struct dl_phdr_info * info;
 > >      size_t size;
 > >      void * ptr;
 > > {
 > >   const ElfW(Phdr) * p;
 > > 
 > > ...
 > > 
 > >   p = info->dlpi_phdr;
 > >   for( i = 0; i < (int)(info->dlpi_phnum); ((i++),(p++)) ) {
 > >     switch( p->p_type ) {
 > >       case PT_LOAD:
 > > 	{
 > > 	  if( !(p->p_flags & PF_W) ) break;
 > > 	  start = ((char *)(p->p_vaddr)) + info->dlpi_addr;
 > > 
 > > 	  if (GC_has_static_roots && !GC_has_static_roots(info, 
 > > size, start))
 > > 	    break;
 > > 
 > > 	  GC_add_roots_inner(start, start + p->p_memsz, TRUE);
 > > 	}
 > >       break;
 > >       default:
 > > 	break;
 > >     }
 > >   }
 > > 
 > > 
 > > ... and a corresponding function in gcj which looks like this:
 > > 
 > > 
 > > int (*GC_has_static_roots)(struct dl_phdr_info * info, size_t 
 > > size, void *ptr)
 > >   = _Jv_GC_has_static_roots;
 > > 
 > > static int
 > > _Jv_GC_has_static_roots (struct dl_phdr_info * info, size_t, void *) {
 > > 
 > > 
 > > So, this implementation depends on weak sysmbols, which in turn depend
 > > on ELF.  For a more generic implementation, it would be better to have
 > > a registration function in the gc with an interface like this:
 > > 
 > > static int GC_register_shlib_conservative_scan_callback
 > >    (int (*GC_has_static_roots)(struct dl_phdr_info *, size_t, 
 > > void *));
 > > 
 > > 
 > > Would such an interface be acceptable?
 > > 
 > > Thanks,
 > > Andrew.
 > >