gij gcj-dbtool and questions

[Jakob Praher]

hi Tom,

Am Dienstag, den 11.01.2005, 14:07 -0700 schrieb Tom Tromey:
> >>>>> "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 :-)

yes I can imagine that :-). I've managed to build gcjx, but I have too
little experience yet to integrate it with gcc, so that all the hooks
work and stuff like that. Perhaps if some of you give me some pointers/a
little bit to get started, I would be interested in trying to get it
working [just to learn a little bit more].

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

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

(1) you are probably right :-) - on the other hand it would be an
interesting option for at least Linux and Solaris. (don't know enough
about Free/Open/NetBsd or QNX here)

(2) mmm yes but that could be solved by a plt like approach, and this
would give more control to optimization, inlining and runtime profiling
of the code

for instance assume that the object base pointer is given in a special
register, like %eax ( on intel these are not that many :-( ), but return
values use them too, anyway.

the compiler on the call site emits 

.text

movl $obj_ptr, %eax
call _OBMLT + index  ; _OBMLT stands for offset based method linkage
table

.plt
; plt stuff

.obmlt
_OBMLT + 0:
; here is the stub for dynamic linking the method with the object 
; all of the information is put on the stack by the information in the
; _OBMLT + index
; this changes the values in the GOT
; but the value in the GOT can also be changed to count the number of
; times for instance, a method is invoked
; or replace it even with a jitted version or something like that.

_OBMLT + index:
jmpl GOT + another_index
; this must be something special which points into the dependency 
; tables, like the R_386_JUMP_SLOT relocation entries
pushl $OFFSET_TO_SPECIAL_RELOC_SYM 

.got ; rw land

_GOT + another_index: ; very .plt like 


this might be a little bit weird to read so please ask me, if you have
any questions. :-)

this example also implies that all the linkage information, like the
method_ref and field_ref stuff (name_and_type, class_name) is contained
inside some kind of symbol tables much like the approach it is done
right now in ld. (now it is referenced by the _Jv_Linker, through the
{o,a,i}table_syms. .

at least this would work with method invocaitons.
i haven't thought about interface invocations too hard yet.
and another thing is that the linker has a flat (i.e. linked list)
global symbol table of all modules - the classloader symbol table, if
you want to call it like that, is a tree structure, where leafs share
the symbols of their parent loaders. this can surely be tracked rather
easily, but is also a fundamental difference. 


okay. and another thing that came to my mind, when thinking about this
stuff, and generalizing the idea. [which might be in some ways not what
the gcj-team is after, since it perfectly works the way it is right now
for java]

what about other data types for signature information? in the current
approach the _sym information for dynamic linkage uses the java
signature format. while I like the syntax of the java signature, it is
rather restricting when it comes to other method references, which could
be theoretically allowed to be called from wihtin gcj, at least for
interoperability with other systems. The reason why I am writing this
here, is that I once played with the idea of implementing this table
linkage for D or one might want to use it to bridge C#.
So another way of storing internal signatures would be to use a type
signatures based on the variable bit rate encoding from llvm and to use
identifiers instead of characters to denote types - which then could
also have modifiers like byref, byval, in, out, pointer, .....
In the end it wouldn't matter too much, I believe, since hashes could
speed up lookup anyways. And in the end such a vbr-bitstream could be
handeld like any other string.


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

okay, that would be a string table like approach, which sounds
reasonable to me. 
> 

thanks for your interesting thoughts.
oh it's already 2 am - I'll better get some sleep now :-)


-- 
Jakob Praher <jpraher@yahoo.de>