delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/11/29/06:05:12

Message-Id: <5.0.2.1.2.20021129103942.0323ebe8@ics.u-strasbg.fr>
X-Sender: muller AT ics DOT u-strasbg DOT fr
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 29 Nov 2002 11:26:17 +0100
To: sandmann AT clio DOT rice DOT edu (Charles Sandmann),
djgpp-workers AT delorie DOT com (DJGPP developers)
From: Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
Subject: Re: DXE enhancements
In-Reply-To: <10211290511.AA14332@clio.rice.edu>
Mime-Version: 1.0
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

At 06:11 29/11/2002, Charles Sandmann wrote:
>I've been hacking on DXEs.  In particular, I want to be able to call I/O
>and other lib routines from DXEs; this will allow us to put big libraries
>such as libiconv there.

Great

>Included below are my current working patches for comments.  There is a
>new switch "-i" which enables the new behavior.  If you use it, it does
>not complain about unresolved symbols, it assumes they will be fixed up
>at _dxe_load time; it then puts the required fixups at the end of the image.
>
>_dxe_load has a corresponding change to check for this new section and
>fix up values.  It needs a fixup vector which is assumed to be set 
>externally before calling _dxe_load in a wrapper.  This fixup vector 
>is currently written to the screen by dxegen; it would be linked into
>images loading the DXE (solves the strip issue).

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 all very lightweight - my example DXE which calls malloc and 
>printf is less than 200 bytes in size; the new dxe_load is only 200
>bytes or more in size.
>
>I also plan to support multiple exports in a future hack, but that can
>be done today manually (the num_exports code below gives hints where
>it goes).

The

>Comments?



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?

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.

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.

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

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?





- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019