[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] binutils
Hi,
sorry for the delay. And sorry for the longish quotes.
Evan Langlois wrote:
On Mon, 2005-08-08 at 15:24 +0200, Guido Flohr wrote:
Hi,
Howard Chu wrote:
If you guys are investigating new binutils and new object file formats,
then now is a good time to invest in developing a re-linkable executable
file format. ELF may be a good starting point; as noted already you can
put whatever sections you want into an ELF file. You could try keeping
the ELF .relo section and just append it to the TOS file image, with an
appropriate pointer to it in the standard TOS symbol table.
I see no real benefit from changing the format of the executables. The
current format provides everything you need, including the relocation
information. Why change that?
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.
The real problem is the lack of dynamic linking facilities which has
nothing to do with the container format of executables. I would rather
No, I don't see how dynamic linking is going to help, especially without
a virtual memory space, which you admit below isn't likely to happen
soon.
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.
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.
In all these cases, a shared code segment in run-time memory is just
nice to have, but not critical.
investigate in the format and logic of shared libraries. If you agree
with me, that MiNT will not see "real" virtual memory management before
the heat death of the universe, and limit expectations to dynamic
linking (as opposed to sharing code sections in memory between
processes), I can't see why the Perl interpreter shouldn't be able to
dynamically load extensions.
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
We have that with LDG, and adding other forms of
run-time linking (without sharing) wouldn't be that difficult since the
loading of the new code is done with a specific library call. Dynamic
linking is linking of libs that are normally static, before the program
begins execution, and without having to call any specific libraries to
load the code. His compromise is to link libraries statically as we do
now, but provide enough information in the executable so that it can be
relinked when you upgrade the library.
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.
Regards,
Guido
--
Imperia AG, Development
Leyboldstr. 10 - D-50354 Hürth - http://www.imperia.net/