The Extension to ELF

[Fumiaki Isoya <isoyaf@gmail.com>]

I'd just sent mail to rms@gnu.org and he replied.

> I know nothing abnout ELF format, and I have not worked on GCC since
> 1991.  Thus, I simply am not in a position to judge the merits of your
> suggestion.  How about writing to gcc@gnu.org, which is the discussion
> list for GCC?

My original message is below.  I'd like to hear your opinion.

> Hello.
>
> This is the 3rd time to send email in this topic.  My first
> purpose in 1994 was to make a simple and lightweight OO language
> which can run on 32bit native DOS.  I planned the implementation
> of C structure which has the first variable of a pointer to its
> class.  And I considered about the class which contains a pointer
> table for instance methods.
>
> ------------------------------------------------------------------------
> class Object {
>     int a, b;           /* instance variable */
>     void do0 ();        /* instance method */
>     void do1 ();
>     void do2 ();
>     void do3 ();
>     void do4 ();
> };
>
> Object obj;
>
> ------------------------------------------------------------------------
> [MEMORY IMAGE]
>
> Object
> +-----------+
> | Ptr super |
> | Ptr do0   |
> | Ptr do1   |
> | Ptr do2   |
> | Ptr do3   |
> | Ptr do4   |
> +-----------+
>
> obj
> +-----------+
> | Ptr class |---> Object
> | int a     |
> | int b     |
> +-----------+
>
> ------------------------------------------------------------------------
> class Point extends Object {
>     int x, y, z;        /* instance variable */
>     void do2 ();        /* instance method (override) */
>     void do5 ();        /* instance method */
>     void do6 ();        /* instance method */
> };
>
> Point  pt;
>
> ------------------------------------------------------------------------
> [MEMORY IMAGE]
>
> Point
> +--------------------+
> | Ptr super          |---> Object
> | Ptr do0            |
> | Ptr do1            |
> | Ptr do2            |
> | Ptr do3            |
> | Ptr do4            |
> | Ptr do5            |
> | Ptr do6            |
> +--------------------+
>
> pt
> +-----------+
> | Ptr class |---> Point
> | int a     |
> | int b     |
> | int x     |
> | int y     |
> | int z     |
> +-----------+
>
> ------------------------------------------------------------------------
>
> Even with this simple plan, trying to implement was very difficult
> because I was going to keep the principle "What is necessary is to
> re-compile only the source files you touched".
>
> Consider the class, for example, which has 5 instance methods.
> The derived class adds 2 methods and overrides 1 method.  The
> object files are separate into two.  The symbols of indices (in
> asm file) will be something like the below.
>
> Object_super    .define 0
> Object_do0      .define 4
> Object_do1      .define 8
> Object_do2      .define 12
> Object_do3      .define 16
> Object_do4      .define 20
> Object_MMAX     .define 24      /* Method MAX */
>
> Object_class    .define 0
> Object_a        .define 4
> Object_b        .define 8
> Object_VMAX     .define 12      /* Variable MAX */
>
>
> Point_super     .define Object_super
> Point_do0       .define Object_do0
> Point_do1       .define Object_do1
> Point_do2       .define Object_do2
> Point_do3       .define Object_do3
> Point_do4       .define Object_do4
> Point_do5       .define Object_MMAX .+ 0
> Point_do6       .define Object_MMAX .+ 4
> Point_MMAX      .define Object MMAX .+ 8
>
> Point_a         .define Object_a
> Point_b         .define Object_b
> Point_x         .define Object_VMAX .+ 0
> Point_y         .define Object_VMAX .+ 4
> Point_z         .define Object_VMAX .+ 8
> Point_VMAX      .define Object_VMAX .+ 12
>
>
> The object file of the derived class doesn't know the length of
> the method table of the super class, nor the index of the method
> to override.  The calculation of constants to generate a suitable
> method table must be ld's job as long as we keep the principle.
> Take care this is not about the method dispatch.  This is about
> the classes as global variables which is generated by ld.  It
> contains a flat pointer table of instance methods.  How do you
> think about this principle?
>
> I suspect we should make decision of solving all symbols by the
> calculation.  That is, all symbols should be solved by the
> calculation of the information that stored in Reverse Polish which
> consists of constants, other symbols, and their arithmetic.  It
> also contains the information of shared libraries possibly.  I
> suppose this decision gives unified implementation of object
> files, static libraries, and shared libraries.  In fact it will be
> the extended ELF.
>
> Please forgive me because I'm not any linker expert.  I don't know
> very much the details of ELF format.  I know m68k asm, but I only
> regards ld as a kind of constant resolver.  I even don't know
> really well about dynamic linking.  But I believe this kind of
> solution will be the best infrastructure (binutils, and the
> mechanism of shared library) for the object oriented languages.
> I'm not interested in designing OO language, I'm just talking
> about infrastructure.  I imagine the goal of this infrastructure
> is to provide seamless linking of OO language's object files, C's
> object files, and Asm's object files.
>
> I had read the article of the interview to Straustrap so many
> years ago and he had said "My work is to design the language, I'm
> not interested in implementations" or something like it.  In
> contrast with it, my interest is implementations.  How do you
> think about the great effects which he brought with his stance?
>