X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10201222135.AA27283@clio.rice.edu>
Subject:	Cross Build DJGPP support on Big Endian Unix
To:	djgpp-workers AT delorie DOT com (DJGPP developers)
Date:	Tue, 22 Jan 2002 15:35:33 -0600 (CST)
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com

I've been hacking on DXEGEN.  The new version uses a few more of the
symbol information tidbits.  The problem is I'm not sure I can get the
endian stuff fixed right without testing it.  It was used when cross
building DJGPP on a big endian architecture.  Do we still need this?
If so, does anyone have a test environment?

I don't think I have broken what would be needed to build EMU387.DXE,
but I'm pretty sure that the new symbol import features wouldn't
work properly on a cross compiled big endian box (but that might not
be needed).

Status for the curious-----------

What it currently does:
 new switch -i : do imports.  This makes unresolved symbols no longer
 an error/fatal.  It adds a new set of data fixups to the end of the
 DXE.  It writes a import table.  This import table must be linked
 into the parent image and passed to dxe_load.  dxe_load then fixes
 up these references to point to the parent when loading. Total new
 code is amazingly small.

Let's say we have add(a,b) in a dxe.  Today you have to call the load,
get the symbol, do some extra syntax to call it.  With the new stuff
I'm playng with, add(a,b) could call malloc or printf.  You would 
just have a header which declares add().  You could put the "fat stub"
add() in a library and link it instead of the static version.  In the 
parent program add() "fat stub" does the following:
  1) Checks to see if DXE is loaded - issue, currently don't have 
     function name to file name rules, so hard coded.  Find name on
     path? Not done at all.  Load Dxe if first time.  add() has the 
     import table written by dxegen compiled linked in and passes 
     to dxeload
  2) Once DXE loaded transfers control to DXE routine add()

I'm not sure how much of this eventually goes into CVS, but I get to spend
about 10 minutes a week with it for the last month, and it does some
pretty cool things.  I have a template currently for the fat stub,
but this could actually be written/compiled/ar'ed via DXEGEN.

Extra note: _open has too much code for a "small" loader.  I considered
that LIBC.DXE might always be openable via short name interrupts.

- Raw text -