Organization and symbol lookup for shared libraries

[Andrew Haley]

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > >James Damour writes:
 > > > Bryce McKinlay writes:
 > > >  > Perhaps this step (running gcj-dbtool) could be avoided altogether: if 
 > > >  > the cache is found to be out-of-date at runtime, because someone added 
 > > >  > or changed a shared library without re-running dbtool, then we'll need 
 > > >  > to open those modified shared libraries at runtime anyway. Since we have 
 > > >  > to open them, the runtime could simply update the cache file on-the-fly?
 > > > 
 > > > The problem with that is permissions.
 >
 > What should happen in this situation is for libgcj to fall back to 
 > loading the shared libraries without the cache, and print a warning that 
 > the cache file needs to be updated by running gcj-dbtool.

libgcj would need to take a list of DSOs from the cache and open every
directory that contained one in order to check the date stamp of a
DSO.  But the whole idea of the cache is to load precompiled classes
without any additional overhead for scanning directories, etc.  We
presumably don't want to be in a situation where precompiled Java apps
have a startup time that is proportional to the number of libraries
that are installed.

This check might be a useful debug mode, though.  I wouldn't mind if
it were optional.

 > One thing we do need to consider carefully, though, is security - we 
 > don't want a suid root gcj application blindly opening shared libraries 
 > from user-writable directories!
 > 
 > >Also, there's a potential issue with shared access.  I'm not
 > >sure it's wothwhile.
 > >  
 > >
 > I don't see what the problem is with sharing. Surely, provided the
 > cache file is updated atomically, it will never be seen in an
 > inconsistent state?

The devil is in the details.  Once you'd started to update the cache
you'd want to finish before anything else starts.  There may be
several instances of gcj running, so somehow you'd have to lock them
out while doing the update.  MAP_PRIVATE wouldn't help, because writes
to the region don't affect the underlying file.  So, you'd need to
create a new cache file, copy everything from the old cache into it,
and rename() the new file to the cache.  And you would want to be sure
you were the only process doing that.

There may well be something useful we can do in this area, but I think
we ought to get some experience first.

Andrew.