From: marcov AT toad DOT stack DOT nl (Marco van de Voort)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DXE
Date: 12 Aug 2001 11:41:23 GMT
Organization: Eindhoven University of Technology, The Netherlands
Lines: 48
Message-ID: <slrn9ncqtc.28hj.marcov@toad.stack.nl>
References: <slrn9n5b8t DOT 238t DOT marcov AT toad DOT stack DOT nl> <3B72D840 DOT 50C82D3D AT is DOT elta DOT co DOT il> <slrn9n5tug DOT kt6 DOT marcov AT toad DOT stack DOT nl> <3b755f56 DOT sandmann AT clio DOT rice DOT edu>
NNTP-Posting-Host: toad.stack.nl
User-Agent: slrn/0.9.7.1 (FreeBSD)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

In article <3b755f56 DOT sandmann AT clio DOT rice DOT edu>, Charles Sandmann wrote:
>> 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.

This is what I do now, except that I link with a minimized FPC RTL, and not
the full. This is better smartlinkable.
 
>> 
>> 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.

Yes I know. But I could make a custom strip that kills unnecessary stab
info, and then mutates the binary so that it isn't strippable with a
standard strip.

(and yes, I know that is not ideal from a compability viewpoint, but DXE is
for specialistic purposes anyway.
 
>> 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.

So you can get an address for a mangled symbol in DJGPP too from a stab
binary?


Currently I have exams, but after them, I will pick this up, and hope to
have something running for FPC in september. Then I'll report back here, and
we can discuss an implementation that keeps compability between the two
compilers.