This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Interface between gc and clients to control conservative scan


Andrew -

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.

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? 

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.

Hans

> -----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.
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]