Re: Patch: FYI: loading a class twice

[minyard at acm dot org]

Jeff Sturm <jsturm@one-point.com> writes:

> On 5 Sep 2001 minyard@acm.org wrote:
> > Tom Tromey <tromey@redhat.com> writes:
> > 
> > > I'm checking this in.  This is a reworked version of a patch from
> > > Corey Minyard.  I changed his patch to throw an error instead of
> > > printing a message to stderr.  This seems more correct to me.
> > 
> > Won't throwing an exception leave the system in a "half-baked" state?
> > That might not be good.  I agree that printing the message is not
> > optimal, but it might be better to pre-check the whole thing and
> > refuse the whole object if you find a problem.  I hadn't really
> > thought about it until now (it was just a quick hack), but it might be
> > better to go up a level, grab a lock, and do a scan for problems then
> > install all the classes.
> 
> I had thought libgcj could quietly discard the duplicate class
> registration.  I'm not crazy about either printing a message or throwing
> an exception, frankly... one should be able to override a class in
> libgcj.so (or any other DSO) by placing it earlier in the link order.
> Then ELF dynamic linking semantics ensure only the first copy is visible,
> even during class registration.
> 
> Jeff

Unfortunately, I don't think that's the way the ELF loader works.  It
always takes the most recently loaded code, but the oldest data.  So
if you load a class on top of a double-loaded class, it will take the
code from the last class loaded, but the data items from the first
class loaded.  I'm pretty sure that's the way it works.  We ran across
this when we were testing patching stuff; it's exactly what you want
for patching, but not what you want for this.  I'm not sure what to do
to fix it.

It's late, I'll try to think about it some more tomorrow.

-Corey