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 Subject: Re: DXE enhancements In-Reply-To: <10211290511.AA14332@clio.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 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?