Mail Archives: djgpp/2001/08/09/17:00:55
In article <3B72D840 DOT 50C82D3D AT is DOT elta DOT co DOT il>, Eli Zaretskii wrote:
> Marco van de Voort wrote:
>>
>> Is there more info then the DJGPP faq and source codes, or somebody working
>> on it?
>
> There's no more documentation, but you can ask questions here.
Well,
- I grok DXE as far as I can find in the FAQ/docs.
- I can load and unload DXE's under Free Pascal. The unloading doesn't exist
in DJGPP afaik, but is very trivial. I use a pointer to a record of records
as handle .
- I watch my calling conventions, I can use FPC generated DXE's in DJGPP and
vice versa.
- I ported dxegen to pascal (makes it easier to keep in CVS than the binary),
and gave me a fair understanding
- I even managed to make some mini RTL for DXE's so that I can use Delphi
language feats in DXE's.
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.
This problem is probably 100% analogue to using libc in DJGPP DXE's.
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.
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.
- Raw text -