Re: gij gcj-dbtool and questions

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jakob" == Jakob Praher <jpraher@yahoo.de> writes:

Jakob> BTW: Tom, I am interested in the gcjx stuff, your blog sounds pretty
Jakob> interesting to me. When are you planing on integrating in as a
Jakob> gcc-frontend...

I've been putting off making a branch, mostly because I haven't wanted
to solve the build problems, but also because it is always tempting to
fix another batch of bugs beforehand... fixing bugs and adding code is
more fun than hacking the build system :-)

I'll try to make a gcc branch soon.  I think it will really help gcjx
development for one thing.

Jakob> I am thinking about using relocation symbols and a more GOT/PLT like
Jakob> approach for doing BC compatible linking, also with an application to
Jakob> lazy procedure linking. I have invested pretty much time into the elf
Jakob> dynamic linking approach, since I was very interested how it all worked.
Jakob> I am currently writing a little documentation about that and have to
Jakob> talk to one of my profs, perhaps I can do some sort of this as a diploma
Jakob> thesis, which would be rather nice. The otable and atable stuff is
Jakob> rather straightforwared to implement in pure elf, but the itable thing,
Jakob> is a little bit more tricky, I suppose. After all that calls
Jakob> _Jv_LookupInterfaceMethodIdx, which is a bit more tricky to implement as
Jakob> elf sections.... 
Jakob> Anyways I am providing more information on that, if you are interested.

Yeah, that does sound interesting.  C solves its runtime linkage
problems by changing the system -- why not gcj?  Though honestly I
suspect the answer to this is that (1) we need to support platforms
where we can't hack ld.so, and (2) we need more control over the
timing of class linking than ld.so would provide.

We've also talked many times about having a compiled format with the
minimal number of relocations to process.  For instance, having one
big string for all string data in a class that is referenced by
offset, not pointers.  This is probably the way forward.  One nice
aspect of an approach like this is that we can dlopen() libraries
without RTLD_GLOBAL.

Tom