From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10211291732.AA15107@clio.rice.edu>
Subject: Re: DXE enhancements
To: muller AT cerbere DOT u-strasbg DOT fr (Pierre Muller)
Date: Fri, 29 Nov 2002 11:32:14 -0600 (CST)
Cc: djgpp-workers AT delorie DOT com (DJGPP developers)
In-Reply-To: <5.0.2.1.2.20021129103942.0323ebe8@ics.u-strasbg.fr> from "Pierre Muller" at Nov 29, 2002 11:26:17 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> We could also easily generate an assembler file that would contain the 
> array of external symbols, no?
> The main problem is to find a name that will both be
> 'natural' and respect the Dos limitations...

This is my plan, yes.  I'm looking at either assembler or C.  People 
would be more confortable looking at/hacking C, but I would have to 
give up symbols which don't use the initial underscore (such as "end").

> Yes, sorry, but I tried to patch the dxegen.c that is on CVS tree, but 
> the patch failed at places...
> what version did you use for making the diff?

Sorry.  I committed some patches about a year ago, and it seems I also
re-included those.  I'll send an updated patch soon.

> What about being also able to call functions that would be in other dxe files????
> This would make it almost as good as real DLL.

I believe this should work.  They will have to load in a sequential order
(they can't cross reference).

> This would require that the external symbols are exported  with names
> and that the generated assemble would contain both a
> assembler symboll to the expected name with would be used if the 
> corresponding symbol is loaded statically, but also as
> a string constant that would allow to search through the other dxe loaded.

This isn't strictly true, you can do this without needing to store the
names by insisting that the fixup vector "order" doesn't change.  But to
support the standard dlopen() type functions, it is required.  

> So the assembler file generated would be something like
> 
>    .long  _first_function_wanted
>    .long  .L001
>    .long  _second_function_wanted
>    .long  .L002
> 
> .L001:
>    .ascii '_first_function_wanted'\0
> .L002:
>    .ascii '_second_function_wanted'\0

Yes, this was the plan for multiple exports.  A similar setup for the
imports is designed for validation.

> If the first vlue is zero it means that the symbol is not statically linked
> so we need to search in the exported table names
> of all already loaded dxe to see if we find it...
> 
> Interdependend dxe would probably need several resolution passes...
> Is this too simplistic?

I want to avoid multiple resolution passes - it makes things more complex,
slower, more likely to break.

Functions are quite often jmp directed (similar to the _Exit patch) 
transparently to the user.  Data values should usually reside in the
main image, or would need to be referenced in an indirect manner via
a pointer (can be done in the headers).