Mail Archives: djgpp/2001/08/11/18:00:02
> The last thing is only a hack to avoid the real problem. I'd rather be able
> to use the runtime library from the mainprogram.
To do this you can either:
1) link with libc (-lc) if the routine is standalone and doesn't reference
external data. For example, a string routine works here, but malloc()
doesn't.
2) create a transfer vector for the "call back" routines/data and have the
loader fill them in.
> To perform some late bindings, I though about simply making some mods to the
> DXE format (and increasing the magic):
> - DXEGEN doesn't exit, but only warn on missing symbols. the missing symbol
> names is stored in the DXE too.
> - (not needed for late binding) Instead of one pointer to return, make room
> for a table (one int count, count pointers)
>
> Then, the DXE loader routine must open the COFF binary for stabs, and try to
> calc an address for the missing symbols, and use it to relocate and link the
> missing symbols (both from mainprogram + libc/rtl) with the DXE.
This requires the symbol table not be stripped from the image. If the image
is stripped it fails. The transfer vector approach works even with stripped
images.
> If the DXE loader can't load (e.g. because the bin is stripped) the DXE load
> will fail. Because of the change magic, one loader can be used.
>
> Does this all pass a theoritical sanity check? Afaik it does, at least I
> know that I can find the symbol for an address in stabs, what about the
> other way around.
This could theoretically work, yes. Look at some of the other DXE/DLL tools
in v2tk for examples.
- Raw text -