public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: The Cuthour <cuthour@gmail.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: binutils@sourceware.org
Subject: Re: Introducing ELF2.0
Date: Thu, 30 Jan 2025 23:28:24 +0900	[thread overview]
Message-ID: <944679b1-bb6a-4d77-bec2-83dd78787f80@gmail.com> (raw)
In-Reply-To: <87c28dc3-dab3-4fea-a327-8b907851da5c@gmail.com>


Here, somebpdy?

------------------------------------------------------------------------------

Suppose we have the following two classes:

=== Vec.h ===
class Vec {
     int x, y, z;
};
=== end Vec.h ===

=== Pix.h ===
class Pix: Vec {
     int r, g, b;
};
=== end Pix.h ===

If we add or remove a member variable in class Vec, it requires
recompiling not only Vec.cc but also Pix.cc. I believe this is
a problem. Pix.o should be relinkable.


To solve this problem, I propose the Linkable struct. The term
Linkable struct is proposed in analogy to Linkable function.
C language can be considered a language of Linkable functions.
C language enhances the relinkability of functions by
compromising the optimization of inline functions. C language
does not need Linkable structs because structures are declared
individually in C. Object-oriented languages need Linkable
structs because classes (structures) are described as
differences from their base classes.

To achieve Linkable structs, I propose the Linkable constant.
This mechanism ensures that certain constants are determined
at link time and is realized by extending the ELF format. The
offsets of structure members are defined in a distributed
manner across object files using these constants, with their
values resolved at link time. The information for calculating
these constants is ideally stored in each object file in
Reverse Polish Notation (RPN) for each symbol. The Linkable
constant is also a compromise concerning the optimization of
inline access to structure members.



  reply	other threads:[~2025-01-30 14:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-27 18:26 The Cuthour
2025-01-27 20:16 ` Frank Ch. Eigler
2025-01-27 20:22   ` Frank Ch. Eigler
2025-01-28  4:56   ` The Cuthour
     [not found]   ` <90e29225-b1a4-4df0-9106-898130e9da82@gmail.com>
2025-01-29  3:05     ` Frank Ch. Eigler
2025-01-29 16:25       ` The Cuthour
2025-01-29 17:44         ` Frank Ch. Eigler
2025-01-29 18:26           ` The Cuthour
2025-01-29 18:52             ` Frank Ch. Eigler
2025-01-29 19:21               ` The Cuthour
2025-01-29 19:49                 ` Frank Ch. Eigler
2025-01-29 22:26                   ` The Cuthour
2025-01-29 22:54                     ` Frank Ch. Eigler
2025-01-29 23:25                       ` The Cuthour
2025-01-30  5:55                         ` The Cuthour
2025-01-30 14:28                           ` The Cuthour [this message]
2025-01-30 14:55               ` Nick Alcock
2025-01-30 15:45                 ` The Cuthour
2025-01-28  0:25 ` Oleg Endo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=944679b1-bb6a-4d77-bec2-83dd78787f80@gmail.com \
    --to=cuthour@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=fche@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).