Re: [MiNT] binutils

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Tue, 2005-09-27 at 21:24 +0200, Guido Flohr wrote:

> > Actually, I agree with Howard Chu.  He isn't talking about changing the
> > executable with something incompatible, nor adding something that
> > already exists like relocation information.  The ability to relink an
> > executable provides the benefits of dynamic linking without the
> > drawbacks such as slow load time.
> 
> The migration to ELF is painful: It is an incompatible change, it needs 
> a new kernel version, and it is not trivial to implement.  And there is 
> no benefit that you could not realize with the current format as well.

Again.  It doesn't have to be about switching to ELF.  The features hes
talking about are quite different.  I think ELF would be a good starting
point into research on what is required.

> Think of Perl.  With a working implementation of dlopen() and friends, 
> you can suddenly use all those Perl extensions written in C.  Currently 
> you have to relink the Perl interpreter for that, and I doubt that many 
> MiNT users are able to do that.
> 
> What about Apache modules? You currently have to re-compile Apache resp. 
> relink in order to use a new module under MiNT.

We aren't talking about dynamic loading through dlopen, but dynamic
linking.  In the first, the binary just opens a library by name
explicitly - meaning he does something to make it happen.  No program
headers or anything change, but your source code does.  Libraries are
loaded after the program starts to run.

We already have a similar feature to this.

> And last but not least: Using a shared libc is a huge benefit. 
> Currently you have to relink all executables to make a change in the 
> libc visible.  With a dynamic loader it is sufficient to restart the 
> executable.

This is dynamic linking, which means the shared code is loaded
implicitly - the programmer and source code don't know anything about
the object code loading and sharing.  Instead the program header
information tells the OS what libraries it needs so that the OS will
load them and perform linking after your program loads, but before it
runs.

Howard Chu is talking about an alternative method of solving this
problem.  The way its done in most OSs is "dynamic linking" as described
above.  This means that there may very well be incompatibilities between
the library you have on disk, and what the program expects.  The link
time means that your programs start up slower every time they are run.
In Howard Chu's suggestion, you still have static linking but the
program header contains enough information to be able to relink the
binary at any time.   So to change libc, a program would find every
executable on the system and replace the old libc with the new libc in
the program.  The relinking is done during an upgrade, and not every
time the program loads into RAM.

I don't know if this will negatively affect the ability to share library
program code, although it may be possible to address this as well, once
we have a virtual memory space, assuming an MMU exists.

> > Loading new code into a running program isn't dynamic linking, thats
> > run-time linking.  
> 
> Wikipedia shares my terminology:
> 
> http://en.wikipedia.org/wiki/Dynamic_linking#Dynamic_Linking

You gave two different examples that are very different.

> I don't know LDG (probably after my time) but as far as I can see it, it 
> is not a standard API and does not help to build standard packages that 
> just want dlopen() and friends.

I somewhat agree here, but its what we have to work with, and its pretty
well done.  It is very similar to what you get with dlopen.  I wouldn't
mind someone putting LDG into the OS itself as a generic dlopen() that
can read LDG objects and possibly other formats, but there doesn't seem
to be a huge rush to add such features, and it would be premature to do
so before adding a virtual memory space.
  
-- Evan