On Fri, Jun 16, 2000 at 08:37:35AM -0700, Tom Tromey wrote:
> Jonas> I don't know if this has been fixed or not, but in my
> Jonas> automake-1.4-5 which came with RedHat 6.1, there are bugs in
> Jonas> the main executable, i.e. "automake".
>
> Both the bugs you mention are fixed in the cvs automake.
Great.
> Other than the current support for SUFFIXES, there isn't any way to do
> what you want. There probably could be.
Yes.
> I'm not sure I understand the dynamic loading thing. Are you loading
> perl code? Or something else?
My current wrapper script reads Makefile.khl files and produces
Makefile.am files that in addition to the original content of the
Makefile.khl contains rules for making the special executables like:
dot.klm: $(dot_klm_OBJECTS) $(dot_klm_DEPENDENCIES)
ld $(dot_klm_LDFLAGS) -o $@ -d -r --whole-archive $(dot_klm_OBJECTS)
$(dot_klm_LDADD)
strip --discard-all $@
It finds out what targets needs special rules simply by checking the
*_PROGRAMS variables.
Also implicit rules for using nasm as assembler for .s files are
insert into the Makefile.am. And of course a rule for remaking the
Makefile.am every time the Makefile.khl changes.
The dynamic loader is simply a elf loader which loads the generated
.klm files into memory, resolves undefined symbols by loading
additional .klm files (or fetching the symbol from some external .so
library), mprotect()s the loaded memory blocks and finally executes
the main() method of the initially loaded executable.
The .klm loader has support for system-dependent .klm loading (allows
for optimizing code for i386, mmx, i686-mmx, 3dnow, mips, etc, but
also other than unix systems (dos, etc)), and in some future we will
probably also allow unloading & reloading of .klms so we can keep the
program running at all times.
If we would use dlopen() & friends (or well we do, but just for
loading external .so files) and create .so modules instead, we would
have to either
- fetch the pointers to all functions & variables needed by each
module at startup and storing them in module-local variables, or
- just call the functions directly, which would mean that all
unresolved function calls would go through the dynamic loader for each
call (which would then search for the requested function at runtime),
which is slow, not to mention that external varibles wouldn't work at
all using this approach.
Both approaches means the programmer has to be careful when calling
external functions, referencing variables, etc. In our approach, this
is not necessary. The only disturbing thing is currently that gdb
doesn't (of course) know any of the symbols of the modules loaded
runtime. Hmm, does anyone know is there any way of communicating with
a running gdb ?
> Tom
--
jonas:x:542:100:Jonas Berlin,First Hop Oy,358925172329,358405884454
35895483430:/home/jonas:/bin/zsh
