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: <10112231821.AA18593@clio.rice.edu>
Subject: Re: RFC - Dynamic loading
To: djgpp-workers AT delorie DOT com
Date: Sun, 23 Dec 2001 12:21:56 -0600 (CST)
Cc: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
In-Reply-To: <3C25B25F.697A8992@is.elta.co.il> from "Eli Zaretskii" at Dec 23, 2001 12:30:55 PM
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

> > It would be similar today to debugging a stripped EXE image.
> 
> An analogy with stripped programs is not what I had in mind.  A
> dynamic library can be distributed unstripped.  Since a dynamic
> library eats up its disk space only once, it might actually make sense
> not to strip it, since disk space is not a bug issue anymore.

I agree this would be nice, but the current DXE structure has no place
to store symbols.  I was proposing a simple fix to DXE which would allow
it to be used for more general purposes.  For example, the WIP dxegen
has about 20 new lines, the WIP dxeload has about 10 new lines.  With
those small changes you can print or malloc from a DXE - and they are
completely backward compatible (except old dxeloads would not be able
to load new DXEs expecting external fixups).

> > At this point it's probably worth while talking about what a DXE currently
> > is.  You take a coff object file, strip the headers and replace the
> > symbols/relocations with a pre-processed compressed fixup vector..
> > 
> > You could take the code inside DXEGEN and have it all done at runtime
> > (for a much bigger loader footprint) using a coff format .o file.  If
> > you wanted to retain symbols for debugging this is probably what you
> > would need for GDB support.
> 
> How about making the debugging info a separate file?  Would that be
> reasonable?  I think GDB could handle that.

Someone would need to design and implement this for GDB if we do something 
new (dxe extension).  If we followed some other DLL path then it would need
to be re-coded.

I see the load size and import locations being the two issues.